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3 TRUCTURE/OVr.RV I cW/ CONVENT IONS 

This document reoresents the structuret overview, and 1 

conventions for V 1.0 of the Ooerating System. 2 

3 

This document will not describe an entire desiqn but rather k 

3 set of interfaces and conventions which should be followed and 5 

improved upon during the detailed desi gn/ i mol ementat ion phase* 6 

This is based on several beliefs? 7 

8 
o The system will change over time, 9 

10 

A defined structure which can evolve is more important 11 

than features or soeed, 12 

13 

o During the push for an operational system* violation of I'f 

good coding/design/ imp lementaion practices will occur. 15 

Having a uniform project understanding will help everyone 16 

recognize when this is haopenina. 17 

18 

o There should be a set of Logical interfaces to physical 19 

resources which give the implementor some insulation from 20 

the way the physical resource looks or is being managed. 21 

22 

There will pe multiple variants of the Operating System 23 

with all Product Set » User and Command Language 2^ 

(Operator/User) Codes transportable between variants. 25 

26 

The next uodate of this document will concentrate on a more 27 

detailed description of tables in Section 2, ^. 28 
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1*0 SYSTEMS COMMAND j. 



laOLL 



The Command Langugqe Is an external izat ion of the Operating 
System. Almost all Users (system, application, operations) will 
come in contact with this interface. A major objective of the 
external design is tailoring to the type of user, while a major 
objective of the internal design is modularity and 
maintainabi I ity. 

Several characteristics of the Command Language include: 

o It is a true language with enough capability to solve 
simple problems. 

o Most Command Language statements are MACRO calls and 
result in the execution of several Operating System 
primitives. 

o User to System communication is through a symbol table 
(Logical Name So^ce). 

o Input to the Command Language interpreter can be 
redirected to previously fi led commands. 

o It is invariant to the mode of access, e.g. , Local Batch, 
Interactive, Remote Batch. 

o Some services supported by the system will be implemented 
using Command Language. 

This command language interface can isolate the end user 
from underlying system requests providing a level of consistency 
and reliability above that available i f these requests were 
directly called. Command Language syntax and parameter rules 
must be followed by all subsystems (debug, edit, online 
maintenance, operator, etc.). 
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1.0 SYSTEMS COMMAND LANGUAGE (SCL) 
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The approach out I ined above is the one that has been adopted 
for the IPL System Commend Language. Three logical environments 
are defined* one for the normal user, one for the system user and 
one for the system operator. Thss** environments are controlled 
by three repertoires called the User, System and Operator 
Repertoires respectively. These three repertoires are not 
mutually exclusive and therefore a system user can have both the 
System Repertoire and the User Peoertoire attached at the same 
ti me. 
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User Repertoire Summary 
L0GIN/J03 
LOCK 

L0G0UT/J08ENQ 
LIMIT 

CLAIM 

CHANGE 

RESERVE 

CANCEL 

ACQUIRE 

RETURNR 

DECLARE 

REMOVE 

LNS. 

LNSBLOCK/LNSEND 

FORTRAN 

COBOL 

SWL 

COMPILE 

LIBRARY 

OBJECT 

EXECUTE 

ATTACH 

DETACH 

CREATE 

EXPAND 

CONTRACT 

SAVE 
DELETE 



gain access to the system 

lock the terminal preventing inadvertant 

logout 

relinquish access to the system 

limit the amount of resources the } ob 

can consume 

set maximum usage for a class of devices 

for a job 

increase or decrease number of units of 

a class 

register the requirement for a 

non-preemptible resource 

cancel all previous RESERVE requests 

satisfy all previous RESERVE requests 

return a file, volume set, or unit set 

to a job 

declare an Ins entry 

remove an Ins entry 

add or delete entries from Ins segment 

list 

delimit an LNS naming context 

invoke the FORTRAN compiler 

invoke the COBOL compiler 

invoke the SWL compiler 

invoke default compiler or use file data 

type attribute 

add or de I ete entri es on a Library List 

add or delete entries from a Object List 

cause the named program to be loaded and 

executed as a task 

attach a permanent mass storage file to 

a job 

detach a permanent mass storage file 

from a job 

allocate mass storage space for a 

temporary or permanent file 

allocate additional mass storage space 

for existing temporary or permanent file 

release part or all the mass storage 

space allocated to temporary or 

permanent file 

convert a temporary mass storage file to 

a permanent file 

deletes a temporary or permanent file 



1 
2 
3 

if 
5 
6 
7 
6 
9 
10 
11 
12 
13 
Ik 
15 
16 
17 
18 
19 
20 
21 
22 
23 
2k 
25 
26 
27 
28 
29 
30 
31 
32 
33 
3k 
35 
36 
37 
38 
39 
kQ 
kl 
k2 
k3 
kk 
k5 
kb 
k7 
kB 



NCR/CDC PRIVATE REV 30 MAY 75 



NCR/CDC PRIVATE REV .30 MAY 75 



ADVANCED SYSTEM LABORATORY 
STRUCTURE/OVERVIEW/CONVENTIONS 
i.O SYSTEMS COMMAND LANGUAGE (SCL) 



CHPOaOif 



1-5 
75/05/30 



ADVANCED SYSTEM LASQP.ATORY 
STRUCTURE /OVERVIEW /CONVENTIONS 
i.O SYSTEMS COMMAND LANGUAGE (SCL) 



CHP020^ 



1-6 
75/05/30 



REDEFINE 



PERMIT 

PROHIBIT 
CONNECT 

DISCONNECT 

ROUTE 

DIRECT 

RETRACT 

PRINT 

PUNCH 

SEND 

MAIL 

DELETE 

TIMER 

WHEN/WHENENO 

WAIT 

CAUSE 

CLEAR 

ENABLE 

DISABLE 

SUDMIT 

STOP 

START 

TERMINATE 

DISPLAY 

CALL 

RETURN 

IF/IF END 

GOTO 

ACCEPT 

COLLECT 

COPY 

DEFINE 

BEGIN/END 

FOR/FORENO 

LABELQLOCK/LARELEND 



from the system 1 

redefine some of the logical 2 

characteristics of an existing permanent 3 

mass storage file k 

gives or modifies access(x) to filety) 5 

for user (z) 6 

removes access (x) to file(y) for user(z) 7 

establish connection between stream and 8 

file 9 

remove connection between stream and 10 

file 11 

transmit a file 12 

alter the destination of a file 13 

remove the effect of a previously issued 1** 

DIRECT request 15 

print a f ile 16 

punch a file 17 

send a message to a user or set of users 18 

mail a message to a user or set of users 19 

delete the contents of a user's mailbox 20 

select a time condition 21 

associate a series of commands with a 22 

specified event 23 

await the occurrence of a specified Zk 

event 25 

cause the occurrence of a specified 26 

event 27 

clear a specified event 28 

enable a specified event 29 

disable a specified event 30 

submit a new job to the system 31 

stop processing of task or job 32 

restart processing of task or job 33 

terminate orocessing of task or j ob 3'» 

display the contents of a file or Ins 35 

value 36 

process the SCL text contained in a file 37 

return control from a called file 38 

delimit conditionally processed commands 39 

transfer control to the label specified ^0 

read data from the standard input '♦I 

collect data from the input stream kZ 

copy data i*3 

define new commands and redefine system ^'f 

suppi ied commands kS 

delimit a command block 'f6 

delimit a FOR loop ii7 

delimit an SCL label block ^8 



MICRO 

SET 

RASEFILE 



define a micro 

set or clear SCL toggles 

aopoint file as the base file 
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1.0 SYSTEMS COMMAND LANGUAGE (SCL) 

1.1 OPERATOR(S> COMMAND LANGUAGE 



System Repertoire Summary 

The system repertoire is comprised of a set of commands which 
represent an ex ternal ization of the Operating System requests 
available to a running program. These commands a I low the user 
to invoke most of the Operating System request processors 
directly. The commsind descriptions are contained in the 
various sections of the GDS at the points where the requests 
are def ined. 



1 
2 
3 

5 
6 
7 
6 
9 
10 
11 
12 
13 
1^ 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 
27 
28 
29 
30 
31 
32 
33 
34 
35 
36 
37 
38 
39 
40 
41 
42 
43 
44 
45 
46 
47 
48 



1- 1 OP EPAT OR (S) COM MAND LANGUAGE 



The primary objective of the Operator Communications System 
(DCS) is to orovide a facility whereby both the system and users 
may converse with the human operator (s) of the system or 
network. Specific objectives of OCS are t 

o The system should be flexible and easily extended at the 
si te. 

o The system will have several logical ooerators* each with 
different responsibilities and privileges. 

o The set of logical operators may be mapped onto one or 
more ohysical operators. 

o The hardware and software necessary to support the input 
and output streams of a physical operator should not be 
different from that of any other job doing terminal I/0» 

o Tne system should be capable of operating in a default 
mode without any physical ooerators. 
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1.0 SYSTEMS COMMAND LANGUAGE (SOL) 

1.1 OPERATOR (S) COf^MAND LANGUAGE 



Operator Reoertoire Summary 



REPLY 

INFORM 
STATUS 

SEIZE 

UNSEIZE 

MEMORY 

PATCH 

SET 

SHUTDOWN 

HOLD 

STOP 

START 

RESET 

CANCEL 

ALTER 

ONSYSTEM 

OFFSYSTEM 

BACKSPACE 

FORESPACE 

PAGF 

ONLINE 

OFFLINE 



respond to message issued by a 

OC ^/CONVERSE request. 

send unsolicited input to a Job(s). 

display the status of a system 

recognized entity. 

take over complete control of a hardware 

resource. 

return a previously seized resource. 

display/alter real or virtual memory. 

temporary replacement of a system 

procedure. 

set various system operational valves. 

close down a site in an orderly manner. 

suspend activity at natural boundary 

suspend an activity immediately. 

restart previously suspended activity 

reset an activity to beqinning point. 

stop an activity and purge it from the 

system. 

change/alter Job's operational values 

assign a d9vice to the system job. 

release a device from the system job. 

bacK up an output listing. 

skip forward an output listing. 

print a specified number of pages. 

add a device to the conf igura ton. 

delete a device from the configuration. 
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Command Availability Summary 

The following table Illustrates the availability of commands 
to different levels of operators and the activities that may be 
affected by them. The following abbreviations are used in the 
table. 

ok no restrictions 

na not available 

— > included via lower level repertoire 

system entire system 

q input or output queue 

ooq output queue 

ropq remote batch output queue 

job job 

rjob remote origin job 

opQjob job in outout queue or function 

ropqjob job in remote batch output queue or function 

dev device 

sysdev "onsystem" device 

rdev remote batch te^^minal device 

rsysdev remote batch terminal "onsystem" device 

To use the table, locate the intersection of the command 
name and the logical operator job name. The activities that may 
be referenced by the command when used by the particular logical 
operator are all those to the right of the intersection in the 
row for that command. If an arrow ( — >) is encountered* follow 
it. . 
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CE//OP SE#OP SYSTEM/AOP MASSZ/OP 

TAPE#OP 
BATCH /^OP 



REMOTE#OP 



reply 


oK 


ok 


ok 


ok 


r job 


Inf orm 


Ok 


ok 


ok 


ok 


rjob 


status 


oK 


ok 


ok 


ok 


ropq 
rjob 
rdieM 


seize 


ok 


na 


na 


na 


na 


unseiz e 


ok 


na 


na 


na 


na 


memory 


--> 


ok 


na 


na 


na 


patch 


--> 


ok 


na 


na 


na 


set 


> 


— — > 


ok 


na 


na 


shutdown 


--> 


-- > 


system 


na 


na 


hold 


--> 


--> 


system 

q 

j ob 


opq 

opqjob 

sysdev 


ropqj ob 
rsysdev 


StOD 


— > 


--> 


system 

q 

job 


opo 

opqjob 

dev 


ropqj ob 
rdev 


start 


--> 


--> 


system 
job 


ooq 

opqjob 

dev 


ropqj ob 
rdev 


reset 


--> 


— > 


job 


opqjob 
sysdev 


ropqj ob 
rsysdev 


cancel 


--> 
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job 
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opqjob 

sysdev 
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alter 
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--> 


job 


opqjob 
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1.1 OPERATOR (SI COMMAND LANGUAGE 



CEfAOP 

onsystem --> 
of f system — > 
backspace — > 
forespace--> 
page — > 
on I ine — > 
of f I ine — > 



SE#OP 



SYSTEMfAOP MASS^OF 
TAPE#OP 
BATCHf/OP 



REKOTE^OP 



— > 
--> 
-- > 
--> 



dev 


rdev 


dev 


rdev 


sysdev 
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1.1 OPERATOR (S) COMMAND LANGUAGE 

JOR WJH "COBOL COMPTLE AND EXECUTE" 1 

COLLECT SOURCE 2 

3 
. COBOL SOURCE DECK APPEARS HERE if 

5 

*♦ 6 

COBOL I=SOURCE, 0=OBJECT, L=LISTING, S=ERR 7 

IF ERR. LEVEL GT 8 

PRINT LISTING 9 

JOPEND 10 

IFEND 11 

SAVE OBJECT 12 

OBJECT ADD=08JFCT 13 

COLLECT DATA UNTIL = /. Hi 

15 
. DATA HECK APPEARS HERE 16 

17 
/. 18 

EXECUTE PROG = MAIN, PARAM=DATA 19 

JORENO 20 

21 

22 

JOB WHJ "COBOL EXECUTE ONLY" 23 

OBJECT ADO=OBJECT 2if 

COLLECT DATA UNTIL = /. 25 

26 
. DATA DECK APPEARS HERE 27 

28 
/. 29 

EXECUTE PROG=MAIN, PARAM=DATA 30 

JOBEND ' 31 
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2,0 STRUCTURE 

2,1.1 MULTIPLE MONITOR CONCEPT 



2.0 ^£U£IUS£ 



2*1 IN TRODUCTION . 



As the number of concurrent users has increased. Operating 
System structures have become more sensitive to integrity 
oroblems. 
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2.1.1 MULTIPLE MONITOR CONCEPT 



The Operating System is trying to generalize the 
User-Supervisor situation. This concept of multiple monitors, 
each in charge of a single shared data base, is analogous to the 
approach used for many large resource management problems! i.e.» 

o Implement levels of responsibility and isolation where 
each level is knowledgeable and responsive to requests in 
a local environment. 

o Requests at the same level may operate concurrent I y with 
other environments. 

o Requests which caTnnot be processed at a local level are 
automatically routed to a more global level. 

o Reduction in responsibility of any one level reduces the 
impact of failure. 

As the concept of multiole monitors has evolved, two 
accepted techniques have appearedt 

o Separate address space for each monitor 
(Master, OS/MVT, Cyber) 

o Monitor(s) within each address soace 
(PL, Multics, 0S/VS2) 

Recent Operating Systems contain both interfaces, with the 
degree of support being heavily influenced by the sophistication 
of the hardware. 
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2,1.2 HISTORY 
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Two characteristics which have changed drastically over the 
time period of these systems are the advances made in storage 
technology (size» costt speed* reliability of Disk Memory* plus 
the hardware assisted techniques for storage management) and the 
great increase in the services expected of an Operating System. . 



These two 
to Mowing way: 



factors have impacted the O.S. evolution In the 



BIS advocates translating all requests for service into a 
Task which an EXECUTIVE will apply to an available processor. 
The EXECUTIVE has three basic types of servicesi processor 
assignment, call routing (a ca I I is a request for work made by 
one task on another task)* and signal handling (inter-task 
communication). The main problem encountered is the overhead of 
the executive. BTS advocates imp! ementl ng these basic services 
in the processor in order to gain the necessary efficiency. 



Since there is 
services in hardware* 
taken. 



a reluctance to implement specific O.S. 
a slightly different approach must be 



One way to reduce the overhead induced by the executive is 
to not use it. This megns a set of O.S. services are placed in 
the environment of the requesting program* thereby eliminating 
the trip through the executive that was previously required in 
order to access the services. 

This concept must not be used to the extreme or a new set of 
problems will result as the Multics Operating System demonstrates 
(i«e. global resources, such as processors and physical memory^ 
should be managed outside of the requestors environment). 
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The IPL Operating System will provide 
in both local and global environments. 



services implemented 
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2.1.3 IMPLEMENTATION 



For the multiple monitor conceot to work» a formal set of 
hardware and software conventions must be imposed on both user 
and system code. This will allow the normal debugging, 
linking/loading, code maintenance* accounting and checkout 
methods of the user and the system to be the same. This also 
facilitates the movement of code between let/els and allows 
recursive use of the system. These conventions will cover? 

o Fntry/Exit 

o Parameter Passing 

o Parameter Validation 

o Address Space Management 

o Memory Management 

o Protection Environment 

o Naming Environment 

o Code Generation 
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CONVENTION IMPLICATIONS 

ENTRY/EXIT 

o Sharing code requires that the control path is remembered 
outside of the code body. 

o Protection implies that separate stacks are maintained for 
each level of privilege and that correct entry to each 
level can be guaranteed. 

o Ex ternal izat ion to subsystem writers implies the existence 

of a way to add or delete protected entry points 

associated with the subsystem without doing a system 
generation. 

o Asynchronous operation implies separate machine 
environment, scheduling information (status, priority)* 
and monitor intervention for coordination. 

PARAMETER PASSING 

o Asynchronous operation implies the need for either 
synchronization primitives (if parameters are in shared 
space) or movement of parameters through a neutral storage 
area. 

o Protection requires no inadvertant destructions of 
communication areas which may imply copying, hierarchical 
per'missions and read only solutions. 

o Location transparency (separate address space, separate 
systems) implies the existence of intervening procedures 
to collect/dispose and transmit/receive oararreters. 
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PARAMETER VALIDATION 

o Parameter validation requires that the 
caller is guaranteed to be correct. 



identity of the 



Parameter validation reauires the type of oarameter to be 
Known. This in turn implies that descriotive information 
exists for all data and is protected seoarately from the 
actual data. 



procedure to 



o Parameter validation requires the executing 
determine its own level of privilege. 

ADDRESS SPACE MANAGEMENT 



o Movement of functions within the system implies the need 
for consistent address space management. Care should be 
used when considering dedicated addresses i acquiring and 
manipulating full pointers, and reusing addresses. 

o Segmentation, with dynamic assignment of segment numbers, 
implies that most information should be accessed and used 
via of f sets. 

MEMORY MANAGEMENT 

o Virtual Memory should permit most knowledge of physical 
memory characteristics to be removed from both Operating 
System and user programs. 
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PROTECTION ENVIRONMENT 

o The fundamental protection unit is 3 segment. The segment 
is an extension of the notion of a file, and can be used 
to address the active portion of the file base. The 
segment descriptor entry provides basic read, write, and 
execute contro I . 

o Two additional descriptors are defined which allow finer 
protection control: 

a. code binding section for Known entry points (hardware 
control I 9d ) 



b. data binding section for 
(software controlled) 



known 



table 



entries 



Both of these descriptors contain type information, access 
control informdtion and pointers to data. 



NAMING ENVIRONMENT 
o 



If users and the system are to communicate, share, and 
control access to information they must use consistent 
naming methods • . 

The active (open files, library lists, etc.) environment 
will be described via LNS descriotors. LNS segments can 
exist ^t th^ system or job level, thus allowing known 
qualifications for known entities. 

The file system will provide a convention for uniquely 
identifying permanently catalogued files. 



CODE GENERATION 
o 



Sharing implies the need for pure procedures which may be 
executed reentrantly. 

Pure procedures require code and data to be separated with 
different protection applied to each. 

Pure orocedures imply that code segments and read only 
data segments do not need to be updated when memory is 
reassigned, thereby reducing I/O and cache clearing 
ooerations. 
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2.1.3.1 3300 IMPLEMENTATION 

The muttiDle monitor concept was suoDorted in the form of 
tasKing on the CDC 3300 Master system. The system-supported 
envelope (task) could contain user or system code. Formal 
interfaces existed for call/return (synchronous and 

asynchronous)? communication and identification ourposes. 

The "OS Task" typically had access to oarts of the O.S. 
data base which had to be protected from the user. The 3300 
system mechanized this interface by maintaining formal 
call/return links* switching page tables (for protection)* 
keeping access information as a task attribute* and serializing 
the entire 'procedure set' when working on shared data. 

The Task interface was used by the subsystem writer when 
adding new functions to the system. This is a valid solution and 
willexist as one type ofinterface in TPL O.S. but contains too 
much overhead for frequently used services such as get/put. 
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The PL Operating System provided an additional interface for 
synchronous reouests which solved some of the overhead problemsJ 

o All code is shared and serialization occurs on data rather 
than code. 

o The 'procedure set' (Task Monitor) resides in each user's 
space* thus simplifying communication between the system 
and the user, 

o A ca I I /return/parameter mechanism was defined for the 
system and user, making system code and user code 
compatib I e. 

o The hardware distinguishes between local (traps) and 
global (interrupts) fault conditions* thus reducing the 
number of trios to a central monitor, 

o The system provides software segmentation on top of a 
hardware-supported linear virtual memory with paging. 

The Task Monitor interface provides a Job mode interface 
through which all requests to the system and responses from the 
system are passed. Some resulting benefits are listed below. 

o Requests/response processing can initially (in some caseSf 
entirely) proceed as a part of the requesting task* thus 
increasing the potential for concurrent processing. 

o Accounting is simpler since no context switch has 
occurred. 

o When requests which require resources ask for them while 
executinci as a part of the requesting task* rejection is 
simpler since remembering who the request is for is 
inherent (current control point). 

o Simpler recovery and consistency codes can be implemented 
since they will execute in the same environment as the 
requestor. 

o It is easier for the system to use itself resulting in a 
more compact. and better debugged system. 

o Increased predictability - most systems have formal 

NCR/COC PRIVATE ^f.y 30 MAY 75 
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conventions for passing information out of an address 
soace but relax that formal ity when returning status or 
setting comoletion indicators. The Task Monitor interface 
reauires formal conventions to be followed when passing 
control information into the address space as well. 

Since most of this interface was software enforced 
(dedicated addresses for user/system area» dedicated entry point* 
passwords, etc.) it would have been very difficult to allow 
subsysem writers to afdd additional protected procedure sets to 
the system. 

This type of interface will exist in the IPL Operating 
System (task services) and will be generalized to allow subsystem 
writers to introduce a similar interface into a. users address 
space, thereby changing the services available to that address 
space. 



1 
2 
3 

5 
6 
7 
8 
9 
10 
11 
12 
13 
1^ 
15 
16 
17 
18 
19 
20 
21 
22 
23 
21* 
25 
26 
27 
28 
29 
30 
31 
32 
33 
3k 
35 
36 
37 
36 
39 
^0 
^1 
kZ 
^3 
kk 
k5 
hb 
k7 
if8 



2.1.3.3 IPL-I M£LE HE NI AIION 



A very positive characteristic of the IPL imo I enentat i on is 
the hardware enforcement which allows the Task Monitor interface 
to be externalized to the subystem writer. The following section 
reviews the advantages, the IPL hardware support and how the 
Operating System intends to use this interface. 

ADVANTAGES AND HARDWARE 

Perfo r manc e 

Calls to protected procedures use the same structural 
mechanism (Call /Return instructions) as calls to unorotected 
procedures with the same cost in execution time. Thus, a 
programmer does not need to consider whether he is calling a 
protected orocedure when estimating performance on new 
designs. 

Reliability. 

Information in the storage system (online mass storage) can 
be read and written by mapping it into virtual memory, and 
then using load and store instructions whose validity is 
checked by the descriptor- mechanism. In addition, the 
addressing privileges of the current protected procedure are 
governed by its identification, which is located in the 
descriptor of the segmert which supplied the most recent 
instruction. Every transfer of control to a different 
procedure is thus guaranteed to automatically produce valid 
addressing. 

Eiexibllilz 

If virtual memory is used, a program can be moved more easily 
to another environment within the system. 

Resource Ma nagem ent 

Management of resources at a local level (via traps, local 
clock, local and global segment attributes) reduces the 
number of calls to the central monitor, thus reducing 
conflicts and increasing concurrency and responsiveness. 

Many system procedures called in a string of references set 
interlocks or record partial results. If these conditions 
are not restored properly in case of failure, continued 



1 
2 
3 
4 
5 
6 
7 
8 
9 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
Zk 
25 
26 
27 
28 
29 
30 
31 
32 
33 
34 
35 
36 
37 
38 
39 
40 
41 
42 
43 
44 
45 
46 
47 
48 



NCR/CnC PRIVATE R€V 30 MAY 75 



NCR/CDC PRIVATE REV 30 MAY 75 



ADVANCED SYSTEM LARORATORV 
STRUCTURE/ OVERVIEW/CON VENT IONS 



CMPQZQk 



2-13 
75/05/30 



2.0 STRUCTURE 

2.1.3.3 IPL IMPLEMENTATION 



ADVANCED SYSTEM LAROPATORY 

S TR UC T UR E/O V EPV I EW/ CONVENT IONS 



CHP02Qif 



2-1^ 
75/05/30 



2.0 STRUCTURE 

2.2 3ASIC CONCEPTS 



system operation n^ay not be possible. The dynamic stack 
represents an efficient way to record and recover these 
conditions. 

Since the system can use itself recursively (with help of the 
Dynamic StacK and Call/Return instructions)* duplication of 
function is avoided resulting in a more com pac t system. 
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2.2 nA£ia_CONe£PIS 



2.2.1 SEGMENTS 



An underlying conceot of the IPL system is a segmented 
virtual address space. The address soace contains all the bytes 
directly addressable by the user. Segmentation organizes the 
address space into two dimensions. That is, all addresses are 
soecified by two components (N,i) where N is a segment number and 
i is a byte number within N. 

The principle benefits of segmentation are! 

a. Convenient oresentation of very large address space to 
the user. 

b. Different access attributes can be defined for different 
segments. 

c. Procedure and data segments may be shared. 



d. Each segment within the address 
indeoendent I y t dynamically expanded. 



be 



The IPL virtual address space prov-ides a range of addresses 
considerably larger than the real memory available in the 
computer. A combination of software and hardware is responsib le 
for mapping the virtual address space into real memory. The 
technique used to perform this mapping is called paging. That 
is» real memory is divided into uniform units called oage frames 
and segments, are divided into units of matching size called 
pages. Only pages which are reouired at a given ooint in time 
need occupy page frames in real memory. 
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2.2.2 LOGICAL NAME SPACE (LNS) 



The IPL Ooerating System is deoendent on the use of tables 
to DTOvide interfaces between different system modules as well as 
between the System and the User. 

Most systems provide methods for the definitioni access and 
allocation/freeing of tables. This interface is typically 
ootimized as a module to module interface. IPL provides an 
additional facility which is optimized as a hjman (Module to 
User) interface and allows symbolic access to table entries 
and/or items within the entry. 

LNS began as a symbol table for the Command Language 
interpreter and grew to a general symbolic access method and 
table manager supporting simple and complex data types. 

This evolution was based on the belief that the system would 
appear more consistent if descriptors for the basic objects of 
the system (File, Task, Job* Unit) were defined* and uniform 
actions applied to these descriptors (START, STOP, DISPLAY, 
STATUS) LNS-managed structures now represent a major portion of 
the environment for any user or Ooerating System module within 
the IPL system. 

The LNS is composed of user and system supplied segments 
containina user and system defined entries. A list, called the 
LNS segment list, is maintained for each job known to the 
system. The LNS segment list contains the names of the segments 
which are to be searched for LNS entries and the order in which 
they are to. be searched. When an LNS entry is sought, each 
segment whose name appears in the LNS segment list is searched 
until the -intry has been found or the list has been exhausted. 

LNS facilities for table handling should be used wherever 
feasible within the system giving a consistency to table 
structure and supporting the notion of a uniform set of reauests 
which can be applied to system descriptors. 
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2.2.3 JORS 



The job is the mechanism through which the batch or 
interactive user interfaces to the IPL system. One Job 
identifies one user to the system, owns and is responsible for 
resources. The Job environment provides a system supported 
accounting, operator communication, logging and recovery envelope 
for all work performed in the system. Every Job consists of one 
segmented address space which is initialized with several system 
supplied code and data segments. 

The normal mode of operation of the IPL Operating System is 
for all jobs known to the system to be in some sense active* 
User validation and command language interpretation are not done 
until a job has been established and has executed for some period 
of time. Thus, very little is known about a job before it is 
executing. Job scheduling is designed to accomodate this mode of 
operation, where jobs must be preempted as they express 
requirements for resources and resumed as the resources become 
avai I abl e. 



A job may grant other 
resource it owns. 



jobs direct or indirect access to a 



DIRECT: This method has one globally held descriptor which is 
pointed to by descriptors held locally to the users of the 
resource. A code segment is an example of a resource 
shared via this method. 

INDIRECT! This method allows a user to access a procedure or 
procedure set which operates on behalf of the resource 
owner. A disk is an example of a resource shared via this 
method. 

The Operating System contains a System Job which has both 
private resources and resources it shares with other jobs. Task 
Services is an example of a procedure set which can execute on 
behalf of its caller (User Job) or its owner (Systerr Job). It is 
intended that the subsystem writer use some of the same resource 
management and control methods used by the System Job. 

IPL Jobs may communicate (via LNS or Signals) and may share 
segments. These capabilities, together with the ability for a 
Job to submit other jobs, allow for the solution of complex 
problems using a simole, well understood construct (the Job). 
Job sequencing may be accomplished by using these standard job 
communication facilities. 
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2.2.^ TASKS 



Every system defines and supports a fundamental unit of work 

which can be uniquely* 

o Identified 

o Accounted 

o Scheduled 

o Allocated/Dispatched 

o Created/Destroyed 
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Descriptions of permanent fi I es are recorded in catalogs 
associated with the storage on which the files are contained. 
Mass storage volume sets contain a catalog of their files and 
available/assigned space in order to permit them to be easily 
transportable among IPL sites. Access control lists allow the 
owners of permanent files to selectively grant access to other 
users or grouos of users. Depending on results of current design 
work, the owner of a permanent file may also be able to restrict 
al I access requests to be issued through a specified program. 

At the time a file is opened for processing, file management 
procedures establish linkage between the user's program and the 
file access procedure (PAP) appropriate for the file organization 
and hardware type. 
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2.2.6 FILE ACCESS PROCEDURES 



File Access Procedures (FAP*s) logically reside between the 
user orogram and a file and provide a standard set of requests 
for accessing data in a file. With one exceDtion* the linkage 
between a user program and a F AP is established when a file is 
opened and severed when a file is closed. The single exception 
occurs when a file is opened for implicit access. In this case* 
the user is returned a segment identifier through which the file 
can be accessed directly with machine instructions - no FAP 
exists. 

Standard file access procedures are defined for both 
block-level and record-level access to a file. Block-level 

access procedures are used primarily by record- level access 
procedures* although they are available to other programs which 
need access to all the bits within blocks of data. 

Standard record-level FAPs are intended for use by the 
Operating System and other products and should be used to process 
any f i le that is a candidate to be processed by another program. 
While this will not guarantee that the contents of the records 
will be intelligible to other programs, it will guarantee that 
the records conform to standard delimiting rules and can be 
located within larger strings of bits. 

Non-standard FAPs are the subject of current design work and 
are intended to assist IPL programs in processing non-standard 
data formats or f i I e organizat ions. The general intent is that a 
non-standard FAP can be written to process a non-standard file (a 
Cyber or Century tape file, for example) using a standard set of 
IPL record- 1 eve I access requests. The OPEN_FILE processor will 
establish linkage to the non-standard FAP by recognizing a 
non-standard LNS file description. 



Notable characteristics of standard record-level 
Procedures are listed below: 



File Access 



o they support the file organizations and access requests 
required by ANSI standard orogramminq languages. 

o where practical, they support additional file 

organizations and access requests needed by the Operating 
System and other products. 

d within reasonable I imitst they provide an interface tor 
sequential record access that is independent of file 
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organization or hardware type. 

o they insulate the user program from the buffering 
technique applied to a file and support both explicit and 
implicit access to mass storage files. 

o current desion work is aimed at supporting concurrent 
access by multiple writers of a single file opened for 
shared update. 
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2«2.7 SECURITY 



Interest in security is currentfy at a high point in the 
"present 3t i on" circles (analogous to structured orogramming the 
last few years) but it is difficult for any imo lementat ion to 
separate what is fundairental in security from complete solutions 
to security. The Operating System objective is to supply a set 
of interfaces and conventions upon which various security 
problems can be solved. 

Although protection/security concepts are not yet formulated 
within the Operating System j a report written by TRW on secure 
Operating Systems is being used to test what is required to 
support security. 

The following security related topics are being explored in 

imo lementat i oni 

o Extending data access control beyond traditional Read* 
Write, Execute and Append categories. For example* Permit 
Write access but only through a specified procedure. 

o Constant review of absolute identification of requestor 
within the system (non-f orgibi e id) to be sure this is 

possible. 

o Constant review of simpUfying the user interface with the 
objective of making it certifiable. (This objective leads 
to reducing the asynchronous action within an address 
sooca ) , 
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2.3 CODE STRUCTURE 

The Operating System supports three basic environments 
within which O.S. services may be ImDJemented: 

System Monitor (one per system) 

TasK Services (within each job) 

System Tasks (within the System Job) 

Every request a user makes of the system will be translated 
into communication with one or more of these environments* 
Whenever O.S. extensions are being implemented* the conventions 
and interfaces of these environments must be understood and 
used. 



System Monitor - That portion of the Operating System that 
is most directly related to the hardware environment and 
providesi 

Directing signals 

o CPU Dispatching 

o Basic CPU Scheduling 

Changing Task Status 

o Interrupt Handling 

System Monitor is interrupt driven* nonpageable* and will 
represent the most thoroughly debugged* least frequently changed 
code within the Operating System. 
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Task Services - That portion of the Operating System that is 
most directly related to the reauestor's environment and provides 
major portions of: 

o Record Management 

o File Management 

o Program Management 

o Storage Management 

o Request Recognition/Routing 

Task Services is always called via a standard callt is 
paged? and h=js the same (clocK) accounting, scheduling and 
execution characteristics as the requestor. 



System Tasks - That portion of the Operating System that is 
relatively independent of the requestor's environment? may be 
asynchronous to the requestor and provides major portions of: 

o Job Management 

o Operator Communications 

o Block Management 

Storage Management 

o Schedul ing 

Each execution of a program is defined to be a task. The 
majority of these executions will be triggered by a signal. Each 
task has its own (clock) accounting* scheduling and execution 
characteristics. All Operating System t3sks belong to the System 
Job. 
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2.3.1 SYSTEM MONITOR 



System Monitor has its own address space and is divided into 
two major componentst the monitor mode Nucleus and the Job mode 
Overseer, 

Nucleus is the only system element that executes in monitor 
mode and cannot tolerate a oage missing interrupt. It is entered 
via hardware i nt errupt . (i .e . , system call, external interrupt, 
access violation, monitor interval timer, etc). All the 
processors in the system share the Nucleus code and its one 
Segment Descriptor Table. However, each processor executing 
Nucleus has its own control point, signal buffer, stack, and 
state registers. When a system call is made to Nucleus, 
parameters are passed via the register image of the caller. 

There are two control points executing Overseer code in job 
nr^o 1^ ^'.r,r^^i w^:..^^ 3P,(j ^3^ tolerate page missing 

This control point performs the 



mode. One is signal driven 
interrupts and wait conditions, 
following functions? 

• Job schedul ing 
Signal buffering 

. Oeadstart 

• Recovery and tracing 

The other control point is both signal driven and dispatch driven 
(i.e., it is per iodical ly dispatched). It cannot tolerate page 
missing interrupts. This control point performs the following 
functions! 

. Error monitoring 

. Wired table management 



Parameters a»"e 
signals. 



passed to each of these control points via 
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2.3.2 TASK SERVICES 



Task Services is 
System services. The 
code, no exchange ju 
instruction can, howe 
called procedure, a 
privileges than the c 
al I ows much of the 
environment. All o 
accounting, schedu I i 
requestor. The only 
code • 



a set of procedures which provide Operating 
se procedures are directly callable by user 
mp or supervisor call is required. The call 
ver, cause a change in privilege for the 
Mowing it to execute with more or different 
ailing procedures. This tyoe of structure 

Operating System to execute within the user 
f Task Services has the same (clock) 
ng, and execution characteristics as the 
difference is access rights to data and 



Task Services provide a central point for the handling of 
all reauests and responses made/^^eceive d by a Task. If the 
service requested is not supported by Task Services, the request 
is passed on to System Monitor or an Operating System Task. 

Task Services occupies two rings (2,3) within each address 
space. The lower ring is used by Task Monitor procedures, which 
will have access to the signals for this address space. Task 
Monitor will move signals out of the signal buffer into an area 
accessabi e by Task Services. The entry to Task Monitor is 
callable from Task Services only. 

In Version 1.0 there is one protected entry point (OS#GATE) 
into Task Services. This allows monitoring of system requests 
and responses. In later versions, based on monitoring results, 
additional protected entry points may be provided. Existing 
programs will still operate, but r ecompi lat ion will be required 
to use the new protected entry points. 

One gate into Task Services will be used exclusively for 
signal processing. A trap procedure will exist in every job at 
the user level (ring). This procedure will, based on trap type, 
call Task Services (signal , clock ..« etc.) or a user supplied 



procedure (overflow 



etc.) 
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2.0 STRUCTURE 

?.3,2.i Request Hgndlinq 



Since each address spgce (job) may contain 3 set of request 
orocessors which belono to a subsystem or System Job» a means of 
identifyinq on whose behalf a request is made must exist. Rings 
wilt be used for this puroosa. Every request orocessor, when 
executing, will have ^ current va I idation I e ve I (ring) which must 
be correctly maintained by the request processor. 

T asK Services code may execute either as an extension of the 
requestor or the System.. When a request is made, TasK Services 
is immediately executing at its most privileged level, that of 
the System. Task Services may use the ring of validation of the 
requestor to access information in an area specified by the 
requestor, thus guaranteeing the requestor has legitimate access 
to that area. 

Note that rings'^arp a global resource such that a ring level 
in every user address soace has the same privilege and belongs to 
either the System Job or a Subsystem vJob. 

Setting the validation level also sets which segment (LNS 
Job Segment) is to be used when searching for descriptors for the 
request made (i.e., System Local tables of the System Job will be 
used when validation level is that of TasK Services). 
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2. 3. 2* 1 Re^ue^t.Handllncj 



Task Services is called via a standard call instruction and 
requires two parameters on entry? one includes a request code and 
a pointer to u request block (inout), the other is an output 
p?irameter which reflects the request status (output). The 
request block is generated by a macro and may contain variables 
which point to additional parameters. The binding of parameter 
values may occur at Compile, Load or Execution time. Since the 
renuest block is moved into the registers before System Monitor 
is called, the Request P I oc k size is limited. 

All requests in the system (inside and outside the address 
space) are assigned a unique code which is used to obtain the 
desired reauest procassor entry. Task Services has a private 
binding section which contains the entry points (code base 
Dointer) for all request processors. The R3 field of each code 
base pointer w i I I determ i ne who can call the associated request 
processor. Task Services will fabricate an offset into this 
binding section using the request code and the callers ring of 
validation. This offset will be used in providing a check on the 
callers access to the dpsired request processor. 

The decision to oass a request beyond Task Services (System 
Monitor) is not made bv the routing mechanism but by the target 
request processor such that the same control oyer entry exists 
irrespective of where implemented. 
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2. 3,2. 3 Major Functions 



2. 3. 2. 2 SiaaaJ Hand! ing 



The Ooeratinq System provides a basic signal handling 
service. The signals have a fixed format* fnaximum size and are 
used by the Ooerating System primarily for communication between 
address spaces. Every subtask has a signal buffer (segment 0) 
which is used for signal queueing. System Monitor is responsible 
for olacing signals into the prober signal buffer and for 
notifying the proper Task Monitor that a signal exists. Task 
Monitor is responsible for taking signals out of a signal buffer 
and passing it to a Task Services signal handler. Routing, based 
on signal type, to a signal processor within Task Services will 
be effected by the Signa"! Handler. 

Task Services will provide a send reauest processor which 
will build a signal supplying the destination, validation level, 
signal tyoe, and selection information. The send request 
processor will then do a system call to System Monitor. 
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2.3.2.3 'Ma i o r Functions 



The major functions of the Task Services procedures are as 
fo I 1 owss 



Record Management 
o 



I og i C3 I 



records 



in 



Providing access to individual 

previously opened files. 

Providing an interface which allows programs to be 

reasonably independent of file organization, buffering and 

device characteristics. 

Providing exit points to usei — supplied application 

procedures. 

Performing automc^tic blocking, deblocking, buffering and 

index management. 



Ea. J.g.,.!J.g^ a.ri.Qf".Q.Q .t 



Supervising the formatting* labelling and cataloging of 

all peripheral devices. 

Manaqing the creation, deletion, labelling, allocation and 

cataloging of files held on mass storage devices. 

Performing open and close operations to logically attach 

and detach files to programs. These files may exist on 

any local or remote peripheral device. 

Verifying that access privilege and privacy rules 

specified by filp owners are followed by af I file users. 



Operator Communications (Job Interface) 

The Operator Communication requests provide for message 
communication between a Job and one of seven logical 
ooerators (tape operator, customer engineer* etc.). If the 
operator with which a job wishes to converse is not logged 
into the system, the information will be passed to/from an 
al ternate. 



Maintaining the LNS search list via the ATTACH and DETACH 

requests, 
o Declaring and removing simple and complex data types, 
o Assigning values into the data types. 
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2.3«2.3 Major Functions 



o Defining new complex types (control blocks) to the 
system. 



Program Commu nic ations 

Program Communications is a set of procedures which provide 
various mechanisms to permit communication and synchronization 
among various parts of programs and among vai^ious tasks in the 
same job. A mechanism is also provided for communication among 
tasks in different jobs. These mechanisms arel 

o Events. Events permit synchronization and interrupt 

control (Attach Interrupt Procedure) for asychronous 

activities within a job. An event is represented by an 

event control block in storage and several requests to 

. manipulate the control block. 

o Signals. Signals are short interjob messages. Signals 
may be sent between arbitrary User Jobs and are also the 
mechanism used to permit a User Job to communicate with 
the System Job. 

o Queues. The queuing mechanism provided allows the 
sending^ storing* and retrieving of arbitrary data 
structures between asynchronous activities within a job» 
A queue is represented by a queue control block in storage 
and several requests to manipulate the queue. 

o Semaphores. Semaphores permit communication and 
synchronization among asynchronous activities within a 
job. A semaphore is represented by a semaphore control 
block in storage and two requests to manipulate the 
control block. Semaphores are the most primitive facility 
supported by the Operating System f or ser iai izat ion and 
synchronization of asynchronous activities. The 
traditional locking functions may be accomplished via 
semaphores. 

o Signature Locks. . Signature Lock(s) provide an 
external izion of the compare/swap hardware instruction and 
is intended for synchronization between Jobs • 

Pro g ram E xecution 

Program execution procedures support the establishment 
loading of programs and procedures and their execution. The 
execution of a program is termed a task while the execution of a 
procedure is termed a subtask. The Loader is considered part of 
program execution. 
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o Loading programs and initiating tasks to execute programs 

and subtasks to asynchronously execute procedures of those 

programs. 
o Controlling tasks and subtasks through declaring* 

initializing* maintaining and removing control point 

structures • 
o Terminating tasks and subtasks normally and abnormally in 

an orderly fashion, 
o Constructing an object module segment* a working storage 

segment and a binding segment. 
Maintaining a symbol table (Loader Symbol Table) of alt 

currently known entries and externals in the program. 

The Loader is responsible for the integrity of the binding 
segments which are among the more important aspects of protection 
in the system. 



£Levice_S£lieduIlni3 

o Allocation of individual peripherals to jobs, 
o Resolution of contention for devices by multiple Jobs, 
o Overcommitment of devices while not permitting deadlock 
between jobs. 

The device scheduler is a set of procedures in Task Services 
which works in close cooperation with the File Management 
procedures in Task Services and the Configuration Manager in the 
System Job. 



Segmen t C o ntrol 



Manage the allocation/release of space on mass storage 

devices in conjunction with file management. 

Manage the a I 1 occft ion/re lease of segment numbers. 

Organize the movement of global segment/file tables 

between memory and mass storage according to usage. 

Organize page working-set sizes a^d move private 

segment/file tables to/from mass storage (swapping). 

Maintain storage system restart information. 

Assist Job Management with the creation of new and 

deactivation of old address spaces. 



Str eam Co ntrol 

o Supporting the connection or disconnection of files to 
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streams, 
o Performing automatic broadcasting to all f i les connected 

to a stream on output, 
o Allowing one file to be connected to N streams reducing 

amount of file resources required. 

These services are externalized for output only and will be 
used by Job Management in creating the logging environment 
(dayfile, errors* account ing» ... ) for a Job. 



System Table Management 
To be supoi ied. 
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2 . 3 • 2 . ^ R equest Summary 



Operator Communication 
CONVERSE 

INFORM 

RECEIVE 

•SELECT 



(Job Interface) Requests 

send a message to an operator and solicit a 

reply. 

send an information message to an operator. 

accept operator input. 

associate an event control block with the 

arrival of operator input. 



Data Management Requests 

(Record Management) 
GET 
PUT 
GETP 
PUTP 
GETO 
GETKEY 
PUTKEY 
DELETE 
DEL KEY 
DELETED 
REPLACE 
FINDF 
FINDP 
FINDKEY 
FINDD 
SETLOCK 
CLEARLOCK 



(Fi le Management) 
DEFINE_FILE 
CR£ATE_FILE 

EXPAND^FILE 

CONTRACT_FILE 

SAVE^FILE 

OELETE.FILE 

ATTACH_FTLE 
DETACH^FILE 



retrieve next re 
store next recor 
retrieve next pa 
store next parti 
retrieve record 
retrieve record 
store record by 
delete previous 
delete record by 
delete record by 
replace previous 
position to firs 
position to prev 
posit ion to key 
position to file 
set a record I oc 
cl ear a record I 



cord 

d 

rtial record 

a I record 

by file address 

by key or ordinal 

key or ordinal 

record 

key or ordinal 

file address 

record 
t record 
ious record 
or ordinal 

address 
k . 
ock 



create a new file control block 

allocate mass storage space for a temporary 

or permanent file 

allocate additional mass storage space for an 

existing temporary or permanent file 

release part or all the mass storage space 

allocated to temporary or permanent file 

convert a temporary mass storage file to a 

permanent file 

delete a temporary or permanent file from the 

system 

attach permanent file to a Job 

detach a permanent file from current job 
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REOEFINE.FILE 

OP&N^FTLE 

CLOSE.FILE 

CLOSE.VOLUME 

PERMIT 

PROHIBIT 



(Block Manaqement) 
READ 

R£AD_DIRECT 
READ^STATUS 
WRITE 

WRITE.OIRECT 
POTNT_FIRST 
POINT_LAST 
POINT^PRECEOING 
POINT^NEXT 
D£VICE_CONTROL 
CHECK 

ASSIGN_BUFFER 
RELEASE.BUFFER 



redefine some of the logical ch3racterlstics 

of an existing permanent mass storage file 

establish a logical connection between a file 

and the current opogram 

sever the logical connection between a file 

and the current program 

close current volume of a tape file and open 

new vol ume 

gives or modifies access(x) to file<y) for 

user(z) 

removes access(x) to file(y) for user(z) 



read next block 

read bl oc-^ direct 

read external status 

write next block 

write block direct 

position to first data block 

position to last data block 

position to preceding data block 

position to next data block 

operate external device 

check for 10 response 



Program Management Requests 



(Logical Name Space) 
LNS.ATTACH 
LN3_DETACH 
LNS_OECLARE 
LNS^REMOVE 
LNS^ENTRY 
LNS_NEXT 
LNS^SLICE 
LNS^GROW 
LNS_LOCK 
LNS.UNLOCK 
LNS_INSERT 
LNS.OELETE 
LNS^GET 
LNS_PUT 

LNS_ATTRIBUTES 
LNS.RECORD 



add a new LNS segment 

remove an LNS segment 

create an LNS entry 

delete an LNS entry 

get descriptor of an LNS entry 

get descriptor of an LNS item or field 

get descriptor of an LNS array element 

expe^nd an LNS entry or item 

lock an LNS entry or item 

unlock an LNS entry or item 

insert a new LNS item 

delete an LNS item 

get the value of an LNS item 

set the value of an LNS item 

set extrinsic attributes of LNS entry op item 

define a new LNS complex type 



1 


LNS_FIELD 


2 


LNS_LOCK_SEGMENT 


3 


LNS^UNLOCK^SEGMENT 


5 
6 


(Program Communications) 


7 


attach:_procedure 


8 


DETACH_PROCEDURE 


9 


STATUS.EVENT 


10 


CAUSE_EVENT 


11 


CAUSE_CLEAR_FVENT 


12 


CLEAR EVENT 


13 


DISABLE^EVENT 


1^ 


ENABLE_£VENT 


15 


WAIT^EVENT 


16 




17 


WAIT_CLEAR_EVENT 


18 




19 


SEND_SIGNAL 


20 


SELECT^SIGNAL 


21 


DESELECT_SIGNAL 


22 


STATUS^SIGNAL 


23 


aiSABLE_SIGNALS 


Zh 


ENABLE^SIGNALS 


25 


IDENTITY 


26 


ENQUEUE 


27 


DEQUEUE 


28 


STATUS_QUEUE 


29 


SIGNAL_SEMAPHORE 


30 


N . ■. 


31 


WAIT^SEMAPHORE 


32 




33 


SIGN_LOCK 


3if 




35 


UNSIGN^LOCK 


36 




37 




38 


(Program Execution) 


39 


EXECUTE 


^0 


EXIT 


kl 


TERMINATE 


42 


SPAWN 


k3 


LOAD 


t*k 


ENTRY 


k5 


REINITIALIZE 


kt 


ESTABLISH 


ikl 




if8 


DISESTABLISH 



define a field of a complex type 
lock an LNS segment 
unlock an LNS segment 



associate inte 
remove interru 
return the sta 
set event to c 
initiate event 
set event to c 
prohibit indie 
a I I ow indicate 
suspend contro 
are caused 
suspend contro 
are caused and 
send a signal 
prepare to rec 
d iscont inue pe 
determine i f i 
disc^ble signal 
enabi e signal 
returns execut 
add item t o a 
remove the fir 
determine if a 
increment se 
waiting contro 
decrement sema 
point i f i ndic 
sign a si gnat 
id of the requ 
unsign signatu 



rruot procedure with an event 
pt procedure/ event association 
tus of an event 

aused and initiate event action 
action and leave event cleared 
I eared 

ated event action 
d event action 
I point until one or all events 



I poin 
set e 
to a j 
eive i 
ceptio 
ndicat 
proce 
proces 
ion id 
queue 
St ite 
ny ite 
maphor 
I poin 
phore 
ated 
ure lo 
estor 
re loc 



t until one or all events 

vents to cleared 

Ob 

ndicated slgna I 

n of indicated signals 

ed signal has arrived 

ssing 

sing 

entity of requestor. 

m on the queue 

ms are on a queue 

e vafue and allow one 

t to continue 

value and suspend control 

ck with the control point 

k by writing with zeroes 



Load and asynchronously execute on program 

Indicates task completion 

used by a task to terminate another task 

start an asynchronous execution of a Subtask 

load procedure not yet referenced in program 

retrieve an existing entry point value 

to support Cobol cancel 

establish a program (subsystem sepvicesi 

within a job 

remove an established program 
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Storage Management Requests 



(Segment Control). 

INITIATE.SEGMENT 

T ERMINATE^SEGMENT 

MARGIN 

MAP_OUT 

SET_MAX 

REL£ASE_UNUSEO 

EXPAND_S£GMENT 

TRUNCATE.SEGMENT 



(Page Control) 
ADVISE_IN 
AOVISE_OUT 
SET_USAGE_LEVEL 
LOCK_PVA 
UNLOCK^PVA 
FIX_PAGE 

R EL EA SEEPAGE 



Miscellaneous Requests 
STREAM_CONNECT 
STREAM_DISCONNECT 
STREAM_GET 
STREAM_PUT 

Job Management Requests 
SUBMIT 
DIRECT 
ROUTE 

SYSLOG 

CLAIM 

CHANGE_CLAIM 
RESERVE 



CANCEL_RESERVE 
ACQUIRE 



define a segment and assign segment number 

remove a file/segment definition 

allows indirect updating of a file/segment 

moves updated pages to primary file/segment 

set maximum segment length 

release unused portion of a segment 

expand segment length 

truncate segment length 



transfer N consecutive pages to memory 
transfer N consecutive pages to mass storage 
give virtual memory usage advice to system 
suspend paging on N consecutive pages 
restart paging on N consecutive pages 
allocate a contiguous section of real memory 
and associate a virtual address range 
return a contiguous real memory section 
allocated by a previous FIX_PAGE 



connect a file to a stream 
disconnect a file from a stream 
input a record from a stream 
output a record to a stream 



initiates 

estabi ishe 

initiates 

specified 

transfer 

error and 

set maximu 

job 

increase/d 

register 

non-preemp 

unit set) 

cancel all 

satisfy 

requests 



the estabi ishment of another lob 
s destination for file to be routed 
the transfer of a file to some 
destination 

information (accounting, system 
dayfile) to the system log file 
m usage of a class of devices for a 

ecrease number of units of a class 

the requirement for a 

tible resource (file* volume sett 

previous reserve requests 
all previously executed reserve 
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RETURN 



SET_PRIORITY 

SET_CLASS 

GET_CAT 

REPLACE.CAT 

GET_CPLT 

REPLACE_CPLT 

GET_CTT 

REPLACE_CTT 

GET_SCT 

R£PLAC£_SCT 



System Table Requests 



System Monitor Requests 
CREATE_ADDRESS_SPACE 
REMOVE_AODRESS_SPAC£ 
. D£FER_ADORESS_SPACE 

RUN_ADDRESS_SPACE 

GET_RJOT_ENTPY 
PUT_RJOT_ENTRY 

CREATE.CP 

R£MOVE_CP 



CHANGE_EXCH_PACK 

STATUS_CP 

CHANGE_CP_STATUS 

0£ACTIVATE_CP 

ACTIVATE^CP 
ENQU£UE_CP 

DEQUEUE_CP 

SELECT_INTERNAL_INT 



return a file, volume set or unit set 

pre\>iously allocated to a Job via 

reserve/ acquire 

estaibi ish/change base priority of a job 

change the class of a job 

get a copy of a record of the class attribute 

table 

replace the cat attribute table record 

get copy of class priority level table record 

replace a class priority level table record 

get a copy of a class transition table record 

replace a class transition tab I e record 

get a copy of the scheduler control table 

replace the current scheduler control table 



To be supo I led. 



create and initialize a new address space 

remove an existing address soace 

transfer a job's working set and tables to 

the jobs swap segment 

retrieve a Job's working set and tables from 

the Job's swap segment 

retrieve a running job ordinal entry 

update the fields of a running Job ordinal 

entry 

reserve memory space and initialize a new 

control point 

terminate outstanding signals deallocate 

stack segements and free control point 

occupied memory 

set specified field within the exchange 

package of a control point 

retrieve a control point's current status 

change a control point's dispatch state 

force a running or ready control point into 

halted state 

remove halt state to make control point ready 

Place one control point into another control 

point's action queue 

remove one or more control points from an 

action queue 

specify the Internal interrupts whose 
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CANCEL_INTERNAL_INT 
SELECT_RFAL_TIME 

CANCEL_REAL_TIME . 
MONITOR^CP 



occurrence should be signaLIed 

remove a orevious selection 

signal control point atter the elapse of a 

real time interval 

remove a real time selection 

permit one control point to monitor a second 

contro I point 
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2.3.3 SYSTEM TASKS 



Many Operating System faci I i ties are provided by programs 
which operate relatively independently of the user. These 
programs are executed as a set of tasks. All but one of these 
tasKs exist in the address space of a System Job. The exception 
is the Sequence Monitor Task. There is an instance of this task 
in every job. The System Job is very much like any User Job with 
one additional characteristic; Task Services/Task Monitor is a 
program in every job which belongs to the System Job and has the 
same privileges and shares the responsibilities of the System 
Job. * 



2.3.3.1 Task s in Ev er y Job 



2.3.3.1.1 SEQUENCE M ONI TOR TAS K 

Sequence Monitor ga'ins control as a result of a Job being 
placed into execution for. the first time. Main control of 
Sequence Monitor issues internal procedure calls to carry out the 
functions of job initiation, command language statement 
processing? user validation* j ob terminat ion and some parts of 
operator communication. 

Job In i tiati o n Procedur es 

The job initiation procedures define standard job streams^ 
create standard job files, perform default file to stream 
connections and additional functions as specifications of job 
structure and environment evolve. 

Comm and ^g n guaqe Interp r eter Proce du res 

The command language interpreter procedures perform the 
functions of login processing, user validation, and command 
language statement processing. " 

Job Te rmina tion P rocedur es 

The job termination procedures perform 
functions: 



the f of lowing 



o Close all files in the job. 

o Release all temporary files in the job. 

o Route all files in the job which have been directed 
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2.0 STRUCTURE 

2. 3. 3.2.2. STAGER SU3TASKS 



previously via DIRECT_FILE requests. 

Remove LNS variables declared for the j ob in System Global 

LNS. , 

Format job termination accounting record and request its 

transfer to the accounting stream. 

Others to be defined. 



Three job termination procedures may be invoked 
procedures other than termination procedures t 



trom 



One procedure is called from the main control procedure of 

Sequence Monitor as the results ot Command Language 

Interpreter processing a LOGOUT. 

One procedure is called from the Command Language 

Interpreter as the result of Command Language Interpreter 

encountering a second LOGIN. 

One procedure is invoked as a result of a signal and event 

occurrence indicating an abnormal situation which is to 

result in job termination. 



2.3.3.2 I as K.s_ln_ tt3 e_S^^ ejTL_ii2 b 



2.3.3.2.1 SYSTEM ACCESS 'HAN AGFR TASK 

The System Access Manager performs the following functions! 

o Validate the newly active terminal • 

o If the terminal is a batch input device t the Stager is 

invoked to service the terminal. 
o If the terminal is an interactive device* the System 

Access Manager does the following: 

* Declares a Job Control Block in System Global LNS. 

• Sets the appropriate values into various fields of the 
JCB. 

. Declares a File Control . Block for the interactive 

device in System Global LNS. 
. Invokes job establishment. 
. Continues to poll the System Input Device List for 

another terminal becoming active. 

The System Access Manager Task is present at deadstart and 
continues to exist until shutdown. 
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2.3.3.2.2 STAGER SUBTASKS 

The Stager performs the following functionsl 

o Opens the batch input device. 

o Declares a File Control Block in System Gl 

disk resident file, 
o Creates this disk resident file as a permane 
o Copies a logical input file from the batch i 
the disk file; 
. A logical input file consists of dat 

between FENCE (system defined delimiter) 
. Stager must also recognize and treat 
defined delimiter) records which may 
logical input file to del ineate points to 
staging, 
o Declares a Job Control Block in System Globa 
o Sets appropriate values into various fields 
o Closes the disk resident file 
o Invokes job establishment 
o Formats a job staging report, 
o Continues declaring FCBs if additional logic 

exist on the batch input device, 
o If no additional logical input files exist, 
• Closes the batch input device. 

Outputs the accumulated job staging repor 
. Terminates execution. 
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There is a Stager Subtask for each active batch input 

device. The number o-f Stager Subtasks will vary during the 

processing day. These executions are subtasks of the System 
Access Manager Task. 

2.3.3.2.3 QUEUED JOB MO NITOR TASK 

The Queued Job Monitor performs the fol lowing fuhctionst 

o Selects highest priority queued job f^om the Known Job 

List, 
o Invokes job establishment ' • 

It may be possible to eliminate the Queued Job Monitor. If 
comprehensive job swapping is provided, job establishment could 
unconditionally establish a batch job by creating a swap file 
image and then linking the swap file into the System Scheduler's 
Deferred Job List. 
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2.0 STRUCTURE 

2.3.3.2.5 JOB ESTABLISHER TASK 



2.3.3.2.^ OPERATOR COMMUNICATIONS 

Each physical ooerator for a site will be reoresented by an 
instance of the Sequence Monitor (includes the System Command 
Language 1 nteroreter ) . This will be accomplished by having a Job 
for each active physical operator. In the minimum case (one 
physical operator) the Sequence Monitor of the system job will be 
used. 

2.3.3.2.5 JOB ESTABLISHER TASK 

The Job Establisher performs the following functionsi 

o Execution is activated by the reception of signals which 
originate from within the SUBMIT request processors of the 
System Job and User Jobs* 
o Determines whether current system imposed thresholds 
permit immediate establishment of another job. 

If immediate establishment is prohibited ao^l the Job 
currently being considered is either interactive or 
batch with no queue permission specified! 

- Issues a reject to the SUBMIT request orocessor from 
which the establishment request ( i .e #, signall 
originated. 

• If imrrediate establishment is prohibited a nd the job 
Deing considered is batch angl, has queue permission 
soecif iedi ^ 

- Constructs ?n entry for the job in the Known Job List 
and marks that entry to indicate it is "not 
estab I ished* . 

• If immediate establishment is permitted: 

- Constructs a swap file image for the job. This image 
will be provided by a system template which contains 
a Sc^gment Descriptor Table image with standard system 
segmentst and images of Control Points and tables 
which will be useo to control initial and subsequent 
execution of Sequence Monitor in the job once it has 
been swaooed into memory. 

- Constructs en entry for the j ob in tne Known Job List 
and marks that ent^y to indicate 'established and 
swaoped-out • , (Note: if the job is one for which a 
Known Job List entry marked as 'not established' 
already existst that entry is remarked as 
'established and swaoped-out ' ) • A fink to the 
relevant swao file is placed into the Known Job List 
entry for the job. 

- Assures the activation of the System Scheduler by 
causinq an p\fQr\t upon which this scheduler waits when 
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there are no requirements for its execution, 
o Obtains another establishment requests if one exists, from 
its signal queue, then begins the process again. If no 
request exists. Job Establishment waits for the reception 
of the next signal from a SUBMIT request processor. 

The Job Establisher Task is present at system deadstart. 

2.3.3.2.6 JOB CO|„L.APSgP "TASK 

The Job Col I apser performs the following functions: 



Execution is activated by the arrival of 
originate from within Job Termination oroc 
signals contain information which identifie 
are to be removed from the system. 
Performs deallocation of job elements which 
for the system's identification and contro 
These elements, therefore, cannot be de 
within the job itself. 
. Deallocates system segments assigned to t 

• Releases job related tables. 

• Rethreads tables where appropriate* 
Releases the swap file associated with th 
Removes the Known Job List entry associa 
job. 

Causes an event to assure activation of Sys 

Causes an event to assure activation o 

Monitor. 

Obtains another COLLAPSE request, if one ex 

signal aue^e, then begins the process a 

request exists. Job Collapser waits for th 

the next signal from Job Termination procedu 
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The Job Coilaoser Task is present at system deadstart. 
2.3.3.2.7 FILE ROUTER TASK 

The File Router performs the following functions? 

o Awakened by signals from the ROUTE request orocessor in 

this job and in User Jobs, 
o Determines identity of file to be routed and the desired 
.routing destination from information accomoanying the 

signal, 
o Determines whether output to the desired destination is 

currently active. 

. If so, Places name of file to be routed in a queue for 
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2.0 STRUCTURE 

2.3.3.2.10 RUNNING JOB MONITOR 



the relevant task of the Output Distributor. 
. If not, invokes the execution of an Outout Distributor 
task and specif i es the identity of the destination and 
the identity of the file to be routed. 

The File Router is present at system deadstart. 

2.3.3.2.8 OUTPUT DISTRXJBUTOR SUBTASKS 

The OutDut Distributor performs the foHowinq functions! 

o Ooens a System Output Device. 

o Transfers a file from disk storage to the System Output 

Device, 
o Closes the output device when no additional files are 

queued for transmission to the System Output Device 

currently being serviced, 
o Terminates execution. 

There is an Output Distributor Subtask for each active 
System Output Device. These executions are subtasks of the File 
Router Task. 

2.3.3.2.9 CONFIGUf^ATION_:MANAGER 

The Active Device Detector is a procedure of Configuration 
Manager and performs the following functions: 

o Detects hardware level signals which indicate that a 

previously inactive device has become active, 
o Associates a hardware signal with a device and places the 

device type and device identifier in the System Input 

Device List, 
o Causes an event or sends a signal to awaken System Access 

Manager. 

The Configuration Manager operation environment will be 
supplied. 

2.3.3.2.10 RUNNING JO B MONITOR 

The Punning Job Monitor performs the following functions! 

o Determines which active jobs should be moved to ready 
status based on time slice and whether the job is waiting 
or not. 

o Determines which ready Jobs should be moved to active 
status based on time slice, whether the Job is waiting or 
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not, availability of enough real memory for the working 
set of the job, and the number of already active Jobs, 
o Performs the state changes for the appropriate Jobs. 



The Running 
deadstart . 



Job 



Monitor Task is present at system 



2.3.3.2.11 DE FERRED J OB MONITOR 

The Deferred Job Monitor performs the f ol 1 owing f unct i onst 

o Determines which jobs should be swapped out based on 
relative priorities, time slices and job status. 

o Swaps out appropriate jobs. Swapping out involves 
collecting together all system tables about the job and 
writing them to the swap file, desMocating all nonshared 
active segments, and changing the job status in the Known 
Job List. 

o Determines which jobs that are swapped out should be 
swapped in based on relative priorities, job status, and 
avai 1 3bi I i ty ~o f system resources* 

o Swaps appropriate jobs which involves reallocating system 
tables and active segments. 

The Deferred Job Monitor Task is present at system 
deadstart . 

2.3.3.2.12 BLOCK, MANAP^R TASK 

Page Control 

Page control is responsible for the management of real 
memory according to usage and scheduling requirements and 
performs the following functions! 

o Maintains* the status of a I I pages in menory and performs 

requests involving the allocation, locking and fixing of 

memory page frames, 
o Performs all requests for the movement of pages from 

immediate access memory to external mass storage and back 

in segment dependent block size, which must be multiple of 

page frame size, 
o Maintains job working set size for scheduling and swap 

control . 
o Controls memory occupancy based on usage and scheduling 

requirements. 
o Performs second level error processing in conjunction with 

Block Management. 
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The Page Control procedures are a part of the Block 
Management program. 

Block Management 

o Controlling the movement of data blocks between buffers or 
segments and previously opened files on oeripherals. 

o Performing second level error recovery for peripheral 
errors that cannot be handled by controllers or channels. 

o Managing buffer, assignment within virtual memory for 
explicitly referenced files. 

2.3.3.2.13 INPUT OUTPUT. DP TVER 3 

To be suppi ied. 
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2.3.4 SYSTEM EXTENSIONS 



System Job/Task Services 

System extension techniques analogous to today's systems 
will be available via system generation. System generation will 
be used when extending task services and/or the system Job. The 
formal interfaces and conventions (OS#GATE< signals* LNSt SWLt 
standard file formats...) defined and used by the intitial 
ooerating system will make extension easier. 



Subsystems 

A fundamental concept of IPLOS is the separation of 
operating system code into two parts? the part that runs outside 
the user address space (System Job) and the part that runs inside 
the user address space (Task Services). Task Services are 
protected from the user by beinq in a lower* more priv i leged ring 
of protection. This allows task services to be directly called 
by the user, to oass parameters by r-eference, and in genera f » 
accrue all the benefits of a common addressing context * while 
retaining protection and integrity. The operating system is not 
the only code for which such a seoaration is desirable. 
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The file system in supporting FAP's will be the Initial user 
of subsystem techniques and will provide the initial example of 
the creation, establishment, calling, execution environment, and 
termination of subsystem code. As the operating system and data 
base management projects orogress, the reauirements for support 
of subsystems will become better defined. 
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2.0 STRUCTURE 
2.^.1 INTRODUCTION 



2.^ DATA gTRUCTUR^g 



Z,k.l INTRODUCTION 



SYSTEM TAGLES 

The Operating System is dependent on the use of tables to 
provide interfaces between different system modules and between 
the System and the User, and to describe the basic objects 
supported by the system and how these objects are related. When 
a tabJe is defined within the system* consideration must be given 
to the following six general characteristics. 

o Protection - Should the information be protected by 

hardware from inadvertent write operations? . Must the 

information be protected from malicious write/read 
operations? 

o Scooe - Should the information be local to a user or 
should it be made global and shareable by other users? In 
general, information should be globally defined only when 
required. Keeping information local to a user has two 
advantages: i) this information is private and no other 
user can interfere with it, and 2) if most of the tables 
required by a Job are collected locally, it is easier for 
the system to keep tracK of a user (restart, paging 
critical tables, etc.). 

o Residence - Should the information be oageable or locked 
down? Wherever possible, information should be pageable. 
It should be locked down only when an obvious efficiency 
case exists. Three points c-^n be madei 1) System Monitor 
cannot tolerate access interrupts, so any information 
referenced by System Monitor must be in real memory at the 
time of reference* 2) I/O channels use absolute addresses 
and require that real memory exists when in operation, and 
3) there are degrees of pageability, that is, some 
information must be present if a task is to use the CPU 
and can only be explicitly removed. An example is the 
Segment Descriptor Table. 

o Addressing - Should the information be symbolically or 
directly addressable? When the user wishes to perform 
program control and data modification functions, he must 
address the system symbolically (Command Language). 
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Therefore, any features which are externalized via the 
Command Language must be supported by symbolically 
addressed tables. Throughout the system, this group of 
tables is referred to as the Logical Name Space (LNS). 

Life Cycle - When will the table come into existance and 
when will it disappear? The data to describe a Job is 
divided into environments which will go away, when the Job 
terminates, when a task terminates, when the system 
crashes, and environments which will live forever unless 
explicitly removed. 

Crash Resistance - When the System crashes, how will the 
tables be reconstructed? What impact will there be on 
recovery if the tables cannot be reconstructed? Will the 
corrupting of the tables cause a System crash? What 
protection will be provided to detect corruption? 
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2.0 STRUCTURE 
2.4.1 INTRODUCTION 



The Operating System table structures are contained in 
several segments which hav/e differing combinations of the 
attributes of protect iont scopef residence* addressing and life 
cycle mentioned before. Every request made by a user will result 
in action aqainst structures contained in the supported 
environments. 

The attributes listed are available in some segments as 
detailed later. Not all combinations of attributes are necessary 
or provided. 

o Protection attributes are: 
directly readafble (OR) 
directly writable (DW) 

interpretlvely readable through LNS (IR) 
interpreti vel y writable through LNS (IW) 
Scope attributes are? 

by the OS in the System Job (SJ) 
by the OS in Task Services in User Job (TSI 
by the user program (USER) 
esidence attributes areS 
pageab I e (P > 

fixed, which implies that some but not necessarily all 
of the segment may be fixed (F) 
swaooable (SWAP) 
Addressing attributes aret 

direct (DA) ., 

symbol ical I y through LNS (SYM) 
ifecycle attributes are* 

for the duration of the system day (SYS) 
for the duration of the job (JOB) 
for the duration of the tasK (TASK) 

There are several segments containing system tables which 
are always present and have known attributes* These are 
described below. User a'nd System Tasks may have LNS» working 
storage, and stack segments with varying attributes which may 
contain some system tables. This will be noted in the 
descriptions of the individual table structures. The segments 
shown in the following table are always supported and have the 
indicated attributes. 
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Figure 2.4.1-1 
SEGMENT ATTRIBUTES 
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2.0 STRUCTURE 
2.^.1 INTRODUCTION 



The Operating System table structures are contained in 
several segments which hav/e differing combinations of the 
attributes of protect ion» scope* residence* addressing and life 
cycle mentioned before. Every request made by a user will result 
in action against structures contained in the supported 
environments. 

The attributes listed are available in some segments as 
detailed later. Not all combinations of attributes are necessary 
or provided. 

. o Protection attributes are: 
directly readatole (OR) 
directly writable (DW) 

interpretivel y readable through LNS (IR) 
interpreti vel y writable through LNS (IW) 
Scope attributes are? 

by the OS in the System Job (SJ) 
by the OS in TasK Services in User Job (TS) 
by the user program (USER) 
Residence attributes areS 
pageab I e (P > 

fixed, which implies that some but not necessarily all 
of the segment may be fixed (F) 
swaopab le ( SWAP) 
Addressing attributes are! 

direct (DA) ., 

symbol ical I y through LNS (SYM) 
.ifecycle attributes are i 

for the duration of the system day (SYS) 
for the duration of the Job (JOB) 
for the duration of the tasK (TASK) 

There are several segments containing system tables which 
are always present and have known attributes* These are 
described below. User a'nd System Tasks may have LNS, working 
storage, and stack segments with varying attributes which may 
contain some system tables. This will be noted in the 
descriptions of the individual table structures. The segments 
shown in the following table are always supported and have the 
indicated attributes. 
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Figure 2.^.1-1 
SEGMENT ATTRI3UTES 
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2.0 STRUCTURE 
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2.^.3 ADDRESS SPACE OF SYSTEM JOB 



DEDICATED SEGMENTSJ 

Signal Buffers for all Running Jobs 

1 In val id 

2 Invalid 

3 Segment Descriotor Tables for all Running Jobs 
k Control Point Buffers 

5 System Global 

6 User Local for this Job 

7 System Local for this Job 

8 User Global 

9 ,System Local for the System Job 



Tas k Mon itor Prog r am Segments t 

10 Code 

11 Working Storage 



Task Serv ices Program Segments^ 

12 Code 

13 Working Storage 



Sequ enc e Monitor Program Se gme nts? 
1^ Code 

15 Working Storage 

S eque nce Monitor T as k Se gmertgt. 

16 Stack for Task Monitor execution 

17 Stack for Task Services execution 

18 Stack for Seau^nce Monitor execution 

19 Binding, for TM, TS, SQ.M 

20 Job Buffer Pool 

21 Rinding for this Job 



NONOFDICATED SEGMENTS: 

' System Access Manager Segments* 
Task 

Stack for Task Monitor execution 

Stack for Task Services execution 

Stack for System Access Manager orogram execution 
Program 
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Code 

Working Storage 
Stager Subtasks (3 stacks per subtask) 
Stack for Task Monitor execution 
Stack for Task Services execution 
Stack for Stager procedure execution 



for Task Monitor execution 

for Task Services execution 

for Job Establisher program execution 



Job EstabI ish e r S egments: 
Task 

Stack 

Stack 

Stack 
Program 

C ode 

Working Storage 

Queued Job Monit or Seg ments: 
Task 

Stack for Task Monitor execution 

Stack for Task Services execution 

Stack for Queued Job Monitor program execution 
Program 

Code 

Working Storage 

Deterr e d Job Mon it or, Segments: 
Task 
Stack for Task Monitor execution 
Stack for Task Services execution 
Stack for Deferred Job Monitor program execution 
Program 
Code 
Working Storage 

Running Job Monitor Segmentst 
Task 

Stack for Task Monitor execution 

Stack for Task Serv/ices execution 

Stack for Running Job Monitor orogram execution 
Program 

Code 

Working Storage 

Job Coll ao ser Segment?: 
Task 
Stack for Task Monitor execution 
Stack for Task Services execution 
Stack for Job Co I I apser program execution 
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2.0 STRUCTURE 

Z.h.k ADDRESS SPACE OF JOB USING A SUBSYSTEM 



Program 
Code 
WorKlng Storage 

FJLL^_Roul£rL_Sg.a!!ientsl 
Task 

Stack for Task Monitor execution 

Stack for Task Services execution 

Stack for File Router program execution 
Program 

Code 

Working Sto»~age 
Output Distributor Subt.asks (3 stacks per subtask) 

Stack for Task Monitor execution 

Stack for Task Services execution 

Stack for Outout Distributor procedure execution 

BJogk Mgn^qer:?eqffienls.l 
Task 

Stack for Task Monitor execution 

Stack for Task Services execution 

Stack for Block Managei" program execution 
Program 

Code 

Working Storage 
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2.^.4 ADDRESS SPACE OF JOB USING A SUBSYSTEM 



DEDICATED SEGMENTS: 

Signal Buffers for all Running Jobs 

1 Inval id 

2 Invalid 

3 Segment Descriptor Tables for all Running Jobs 
k Control Point Buffers 

LNS Seg ments! 

5 System Global 

6 User Local for this Job 

7 System Local for this Job 

8 User G lobal 

9 System Local for the System Job 

Task Monitor Pr ogram Seamentst 

10 Code 

11 Working Storage 

Tas k Serv ices Program Segments! 

12 Code 

13 Working Storage 

Sequence Monitor Prodram Se gments! 
1^ Code 

15 Working Storage 

S-Sjuence Monit or Task Segme n ts! 

16 Stack for Task Monitor execution 

17 Stack for Task Services execution 

18 Stack for Sequence Monitor execution 

19 Binding for TM, TS, SQM 

20 Job Buffer Pool 

21 Binding for this Job 



NONOEDICATED SEGMENTS! 

Sub s ystem Services Program Segm en ts! 
Code 
Working Storage 

Sub s ystem LNS Segmen ts! 
Subsystem Local for this Job 
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2.0 STRUCTURE 

2.^,5 ADDRESS SPACE OF SUBSYSTEM SUPERVISOR JOB 



Subsystem Local for the Subsystem Job 

Stack for TasK Monitor execution 
StacK for TasK Services execution 
Stack for Subsystem Services execution 
Stack for User Program execution 



User Program 
Code 

Working Storage 
Fi les 
Libraries 



mt^8 
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2.^.5 ADDRESS SPACF OF SUBSYSTEH SUPERVISOR JOB 



DEDICATED SEGMENTS: 

Signal Buffers for all Running Jobs 

1 Inval id 

2 Inva I id 

3 Segment Descriptor Tables for alt Running Jobs 
k Control Point Buffers 

LNS Segmen ts: 

5 System Global 

6 User Local for this Job 

7 System Local for this Job 

8 User Global 

9 System Local for the System Job 

Task Monitor P rogram Segments! 

10 Code 

11 Working Storage 

Tas k Services Progrgfrt Segment's; 

12 Code 

13 Working Storage 

Seouence Monitor Program Segmen ts: 
1^ Code 

15 Working Storage 

Sequence Monitor T ask Segments: 

16 Stack for Task Monitor execution 

17 Stack for Task Services execution 

18 Stack for Sequence Monitor execution 

19 Binding for TM, TS, SQM 

20 Job Buffer Pool 

21 Binding for this Job 



NONDEOICATEO SEGMENTS: 

Code 

Working Storage 



Segm en ts: 



Subsystem LNS Segments! 
-Subsystem Local for this Job 
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2.0 STRUCTURE 

2.^.5 ADDRESS SPACE OF SUBSYSTEM SUPERVISOR JOB 



Subsystem Local for the Subsystem Job 

Sub s ystem Suo e rvls or 'Task S e gme nts? 
Stack for Task Monitor execution 
Stack for Task Services execution 
Stack for Subsystem Services execution 
Stack for Subsystem Supervisor Program execution 



Subsystem Supervisor 
Code 

Working Storage 
Fi les 
Li brar ies 



nm ent si 
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2.0 STRUCTURE 
2. if. 6.1 Job 



2.^.6 BASIC SYSTEM OBJECTS 



2.^.6.1 Job 



A job is an entity directly related to a user and has the 
following characteristics! 

there is one address space per job 

o it is the identifiable user of resources (files» devices^ 
memory^ ...) which it can create* control access to» and 
destroy 

o it is the basis of system supported accounting 

o it is the swaopable entity 

o there is one LNS search list per job 

The system maintains several lists that reflect the current 
state of a job as shown in Figure 2.^.6-1 and aret 

o Known Job List (KJL) 

o Deferred Job List <DJL) 

o Running Job List (RJL) 

o Active Job List (AJL) 

The Known Job List contains all Jobs Known to the system 

o Not yet established jobs 

o Swapped out jobs with system segments deallocated 

o Running jobs 

The Deferred Job List contains all those job swapped out. 

o Just established jobs that have not yet been swapped in 
o Jobs that were running but are now swapped out 

The Running Job List contains those Known jobs that are 
established and swapped in. 

o System segments are assigned 
o Active jobs 
o Inactive jobs 
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The Active Job List contains those Running jobs that have 

their working set available in memory. Each control point in an 

active job is on the disoatch chain with a status of either Ready 
or Not -ready. 




Figure 2.^.6-1 
JOB LISTS 
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2.0 STRUCTURE 
2.^.6.2 Task 



2.^.6.2 Tas.h 



A. task is the execution of a program. A standard job has 
two tasks» the execution of the Sequence Monitor program and the 
execution of product set programs or user programs. 

o a task shares an address space with other tasks in the 
job. 

o a task does not own resources. 

o all tasks in a job are swapped together. 

o there is one signal buffer and signal selection list per 
task. . 

o a task may have within it several asynchronous executions 
of procedures* reterred to as subtasks. 

o all the subtasks of a task share the same 
Loader Symbol Table 
. Binding Section 
Signal Buff er 

• Signal Selection List 
. Common 

Object Segment List 

• Library L ist 

. Working Storage 

o each subtask of a task is separately dispatchable and has 
its own 

Control Point 
Stacks 

o the System Monitor maintains a Dispatch Control Table that 
contains control point information 

Status 
. Kind 

Priority 
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Figure 2.^.6-2 
EXECUTION CONSTRUCTS 

PCB Program Control Block 

LNS structure. Can be in any LNS segment. 

TCB Task Control Block 

LNS structure. Can be in any LNS segment local to this 
job. 

CP Control Point 

System table structure. In segment #^. 

SB Signal Buffer 

System table structure. Is in segment #0. 

SSL Signal Selection List 

System table structure. 

QCB Queue Control Block 
ECB Event Control Block 

Referenced by address by system code. Can be LNS structure 

NCR/CDC PRIVATE REV 30 MAY 75 
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2.0 STRUCTURE 
2«^.6.3 File 



in any LNS segment local to this Job. Can also be at any 
RW address in address space of this job (Working storage* 
StacKf Record, etc). 

SDT Segment Descriptor Table 

Hardware table structure. Is in segment #3 for this job. 

JOB Job Control Block 

LNS structure. Is in System Global LNS segment. 



JC3' Alias Job Control Block 

LNS structure. Is in System Local LNS segment 
) Ob . 

EPCB Established Program Control Block 
JST Job Stack Table 
JGT Job Gate Table 
KJL Known Job List 
RJOT Running Job Ordinal Table 
System table structures. 



for this 
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Depending on the users level of interface to the Data 
Man=jgement system, a file may be viewed in the following ways: 

o File Management Level - A file consists of a peripheral 
device or a region of storage on a volume. 

o Record Management Level - A file consists of a set of 
records addressable by key, by ordinal, or by file 

address. 

o Block Management Level - A file consists of a set of 
blocks addressable by block numbers. 

o Segment Level - A file consists of a segment of virtual 
memory addressable by segment number and byte offset. 

The File Control Block Provides the primary interface through 
which a user supplies the definition of a file. 

o A File Control Block must exist before a file can be 
referenced. 

o Cataloged values can replace any existing File Control 
Block values. 

o Values supplied through LNS requests can replace any 
existing File Control Block values. 

o Values supplied through the FM^^OEFINE_FILE request can 
replace only null values. 

o No File Control Block fields can be directly modified by 
the user after the file is created (new mass storage 
files), attached (existing mass storage files) or opened 
(non-mass storage files). 
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2,^.6.3 File 
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Figure ?,^,b'3 
FILE CONSTRUCTS 

Fi I e Control B lock 

LNS structure. Can be in either System Global LNS segment 

or System Local LNS segment for this job. 



Logical File Descriotor 

Buffer Control Table 

Ooen File Table 

File Request Descriotor 

Attached Fi le Table 

Data Management structures. 

this job. 



In System Local segment for 



Physical File Descriptor 

System structure. In system global segment, 

Ooen Descriptor 

Data Management structure. In user memory. 
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2.tt,6.^ Segment 



A segment is defined by a segment number (unique id) » a 
segment descriptor entry (segment attributes)* aid a body which 
is an array of consecutive elements (target data). Since a 
segment cannot wholly reside in memory, a mapping between mGmory 
and mass storage addresses is always maintained by the Operating 
System. Due to varying performance and processing requirements 
this mapping is supported in multiple ways? 

o Direct Segment- a direct mapping between a mass storage 
file and a segment exists, and any modifications made to 
the segment will be reflected automatically in the file. 
Examples would include: 

• Output files 

• Read-only data 

. Program libraries 

o Temporary Segment- a segment which cannot survive beyond 
the life of the^ creating job. Several of these segments 
will be mapped into one mass storage paging file. 
Temporary Segments provide a low overhead mechanism tor 
allocating and managing temporary structures. Examples 
would include: 

Stacks 

Working storage 

Heaps 

Binding sections 

Local LNS 

Indirect Segment- an indirect mapping between a mass 
storage file and a segment exists. Any modifications made 
to the segment are reflected in a paging file, which 
exists for the life of the job and may also contain 
modifications to other such segments. A program must 
explicitly ask the system to reflect the changes back into 
the original file. Examples would include: 

Fi I es being edited 

Periodic updating 

• Batching updates 
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2.0 STRUCTURE 
2«^.6.'+ Segment 
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Figure 2.^.6-^ 
SEGMENT CONSTRUCTS 

SDT Segment Descriptor Table 

Hardware structure. In segment #3 for this job. 

PT Page Table 

Hardware structure. In real memory. 
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PFD Physical File Descriptor 

System structure. In system global segment. 

AFIT Active File Index Table 
SCT Segment Control Table 
MM Memory Map 

Storage Management structures. In system space. 
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3 . CODING/DOCU.MENTJNQ CONVENTIONS 



3.1 INTRODUCTION 

The intent of this section is to record information 
pertinent to the development and i mpl ementat ion of the Operating 
System. It will provide a basis for discussion and improvements* 
and will evolve towards implementation conventions within the 
project. 

3.2 TPLOS NA MING CONVENT IONS 

o The maximum lenqth of al I system and user names and symbols 
will be limited to 31 characters. 

o All IPLOS modules that deal with 1-31 character names must 
be ultimately concerned with the space required to support the 
long names. Wherever feasible* all such modules should use 
space/table allocation techniques that optimize at 8 character 
names with minor performance penalties for longer names (such 
techniques must be invisible to users). 

o Within IPLOS itself* three levels of naming environments will 
exist: 

1) User Visible Names 

1 to 31 characters long 
Maximum mnemonic value 

ex. CAUSE_EVENT 
SUBMIT_JOB 

2) System Global Names 

1 to 31 characters long 
format 

XX?^S..S OR XXX#S..S 
where 
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XX = OS section code string 

XXX = OS section acronym 

# = I i tera I string 

S..S = mnemonic character string 

ex. LNS#ATTACH 

3) Module Internal Name 

1 to 8 characters long 
Mnemonic acronym 

3.2.1 IPLOS SECTION CODE STRINGS 



OS Operating System 

UI User Interface 

IC Input/Output Control 

CL Command Language 

OC Operator Communications 

SA System Access Manager 

FR File Router' 

MG Message Generator 

JM Job Management 

IT Initiator/Terminator 

RA Resource Allocator 

JS Job Scheduler 

AL Accounting/Logging 

CR Checkpoint /Restart 

PM Program Management 

PF Program Execution 

PC Program Communication 

LL Loader/Linker 

LN Logical Name Space 

DM Data Management 

FM File Management 
AP Access Procedures 
BM Block Manager 
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DD Device Drivers 

MM Storage Management (Memory) 

MC Memory Control 
SC Segment Control 

SM System Management 

SS System Scheduler 

CM Configuration Manager 

DS Deadstart 

SG System Generator 

SS System Structure 

SY System Monitor 

TM Task Monitor 

TS Task Services 

SB Subsystem Supervisors 

UT Util ities 

LG Library Generator 

OR Dumo/Restore 

MA Measuring/Analysis 



3.2.2 SOURCE LIBRARY NAMES AND CONVENTIONS 



3. 2. 2. 1 Documenta tion Files 



o Working Document 



A working copy of. each GDS Chapter is under the user id 
MAD with file names CH01...CH12. These are TEXTFORM files 
to which all Operating System personnel have read 
permission. 



o Version ^ GDS 

A file named OSGDSO^ has been created via SCM under user 

NCR/CDC PRIVATE REV 30 MAY 75 
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id DTC and contains a TEXTFORM copy of the 30 MAY 75 
release of the GDS. The deck names are CHPOl. . .CHP12 and 
APDXA...APDXE. Use SCM to retrieve any of this data. 



Conventions 

MODIFY deck names will be equal to document sections < in 
the TEXTFORM context) 

All documentation source will be in TEXTFRM input format 

- The user interface to MODIFY and TEXTFRM will be processed 
thru the standard IPLOS source maintenance commands. 

The major use of the Global Libraries (i.e.* OSOPL» JMOPL» 
•••) will be to contain all system and section global 
table and symbol definitions and declarations. 

ex. SWL CONST definitions 
SWL TYPE definitions 
table declarations 
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3.2.2.2 Sourc e C ode FjMs 



o Library Names 

FORMAT 

XXOPLNN 
where 

XX - 2 letter IPLOS section code 

OPL = Literal 

NN = Version Number of library 

(blanks inserted for clarity» actual name without blank) 

OS OPL 01 Operating System G I obal L ibrary 

UI OPL 01 User Interface Global Library 

IC OPL 01 Inout/Output Control Library 

CL OPL &1 Command Language Library 

OC OPL 01 Operator Communications Library 

SA OPL 01 System Access Manager Library 

FR OPL 01 File Pouter Library 

MG OPL 01 Message Generator Library 

JM OPL 01 Job Management Global Library 

IT OPL 01 Initiator/Terminator Library 

RA OPL 1 Resource Allocator Library 

JS OPL 01 Job Scheduler Library 

AL OPL 01 Accounting/Logging Library 

CR OPL 01 Checkpoint/Restart Library 

PM OPL 01 Program Management Global Library 

PE OPL) 01 Program Execution Library 

PL OPL 01 Program Communication Library 

LL OPL 01 Loader/Linker Library 

LN OPL 01 Logical Name Space Library 

DM OPL 01 Data Management Global Library 

FM OPL 01 File Management Library 

AP OPL 01 Access Procedures Library 

BM OPL 01 Block Manager Library 

DO OPL 01 Device Driver Library 
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MM OPL 1 



MC OPL 01 
SC OPL 01 



Memory Management Global Library 

Memory" Control Library 
Segment Control Library 



SM OPL 01 System Management Global Library 



SS OPL 01 

CM OPL 01 

OS OPL 01- 

SG OPL 01 

SS OPL 01 

SY OPL 01 

TM OPL 01 

TS OPL 01 

SR OPL 01 

UT OPL 01 

LG OPL 01 

OR OPL 01 

MA OPL 01 

SC OPL 01 



Conventions 



System Scheduler Library 
Configuration Manager Library 
Deadstart Library 
System Generator Library 

System Structure Global Library 

System Monitor Library 
Task Monitor Library 
Task Services Library 
Subsystem Supervisors Library 

Utilities Global Library 

Library Generator Library 
Dump/Restore Library 
Measuring/ Ana lysis Library 
Source Code Maintenance Library 



the source librafries will all be maintained in the MODIFY 
program library format 

the use of MODIFY COMMON decks techniques must be 

maximized 



al I O.S. 
decks . 



table declarations must be stored as COMMON 



the library structure should be viewed as a three level 
structure 

o OS global highest 

o Major division global lower 

o Discrete libraries lowest 

All code modules and COMMON decks must be placed at the 
lowest level in the structure possible 
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3.0 CODING/noCUMENTING CONVENTIONS 
3.3 CODING CONVENTIONS 



AM source codina will be done in ISWL/SWL 

- Each MODIFY JECK will represent one and only one ISWL/SWL 

module 

Until such time, as ASL/IPL wide source maintenance 
conventions are developed? a special set of terminal commands 
will be developed and utilized for the IPLOS project. 
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3.3 £OOING_£ONif£NIIONS 



This section will attempt to suggest a few practical and 
probably obvious conventions? with the hope that the list will be 
modified as suggestions from project personnel are forthcoming 
and evolve into a prototype standard. 



3.3.1 DECLARATIONS 

o Arrange declarations into some logical grouping and Identify 
with headings 

CONST 

TYPE 

COMMON FILES 

EXTERNALS 

LOCAL DATA 

o Indent level numbers 

o Identifiers should tend toward self description (within length 
constraints) 

o Be consistent with margins and starting columns for elements 
within declaration statements 

o Position coTipi ler control toggles to the left side of listing 
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3.3.2 PROCEDURES 



Keep procedures small as possible^ one or two pages 

average 

Provide comments for groups rather than individual 
statements in order to maintain continuity of code - do 
not over kill on commenting.. 

One procedure statement per line 

Use indentation for both code and comments 

Avoid use of GO TO statement 
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3.'* SOURCE D OCUMENTAT IO N CO NVE.NTI^NS 

IPLOS will use the SES defined Documentation Prompter 
available under the subsystem for source module documentation. 
An example is as follows: 



/batch 

$RFLt20000.' 

/get , runses/un=a I I 

/get tr undo/ un=soe 

/-runses 

*»MSG i; SES VI. 75/05/30. 09.10.22. -PLEASE LOGIN 

? loain mad-»prof i 1 e=rundp 

♦♦MSG 81? PROFILE PROCESSING INITIATED 

00 0103 0=*PROCEDUREr 

? tentativel y_al locate 

00010^0= 

? = 

00 010^0=»PROGRAMMER: 

? MAD 

0001050= 

•J s 

0001050=*PURPOSE« 

? This procedure determines if an allocation of a 

0001060= 

? particular peripheral to a job can be permitted 

0001070= 

? based on the peripherals current usage* the 

0001080= 

? usage requested* and the possibility of deadlock 

0001090 = 

? if the allocation were made. 

0001100= 

? = 

0001100=*TNPUT: 

? unit:: the unit table entry of the peripheral to be 

0001110= 

? all ocated. 

0001120= 

? req_shareabl e: J boolean set to true if the unit is 

0001130= 

? requested as shareable, false if the unit is 

0001140= 

? requested for exclusive use. 

0001150= 

? rsac:: the current shared* assigned* claimed for the 
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0001160= 



job reflecting any previous tentative allocations. 
0001170= ' 

? = ' ' 

0001170=*OUTPUTt 

? al locat ion_ok : : boolean set to true if the allocation 
0001180= 

? can be Dermitted, false if it cannot. 

00 0119 0= 

? s 

0001190=*METHOO: 
.?■=-, 
120 =*D AT A_US AGE : 

? Dseuclo_avai I ablets arrary of available peripherals 
0001210= 

? reflecting any previous tentative allocations. 

0001220= 
? = 

00 0122 0=*COMPILE_OPTIONSS 
? = 

0001230=*NOTESt 
? = 

00012'fO=*MESSAGES: 
? = 

00 0125 0=^RESTRICTIONS: 
? = 

DOCUMENTATION NOW ON DOCE - SAVE IT 
♦♦MSG 67? RUN COMPLETED 
? I ogout 

**MSG 8^; CONNECT TIME = 00.09.56. 
♦ END SS 1.0 



1 


/edit ,doce 




2 


BEGIN TEXT EDITING 


. 


3 


? J ;* 




*♦ 


" 




5 


*BEGIN DOCUMENTATION! 


6 


♦PROCEDURE! 


tentativel y_al locate 


7 


♦PROGRAMMER! 


MAD 


8 


♦PURPOSE! 


This procedure determ 


9 


* 


particular peripheral 


10 


♦ 


based on the peripher 


11 


* 


usage requested » and 


12 


♦ 


if the allocation wer< 


13 


♦INPUT! 


unit!! the unit table 


Ik 


♦ 


a 1 1 ocated. 


15 


- ♦ 


req_shareab lei ! boo 1 


16 


♦ 


requested as shai 


17 


* 


requested for ex^ 


18 


♦ 


rsac!! the current sh; 


19^ 


♦ 


job reflecting a 


20 


♦OUTPUT! 


al 1 ocat ion_ok« ! boolei 


21 


♦ 


can be pelrmitted 


22 


♦-METHOD! 


NONE 


23 


♦DATA_USAGE! 


pseudo_avai lablei ! an 


Zt* 


♦ 


reflecting any pi 


25 


♦COMPILE_OPTIONS! 


NONE 


26 


♦NOTES! 


NONE 


27 


♦MESSAGES! 


NONE 


28 


♦RESTRICTIONS! 


NONE 


29 


♦END^DOCUMENTATION! 




30 


" 




31 






32 






33 






3k 






35 






36 






37 






38 






39 






kQ 






ki 






kZ 






kZ 






kk 






kS 






kb 






k7 






kS 







ines if an at location of a 
to a job can be oermitted 

als current usage» the 

the possibility of deadlock 

e made. 
entry of the oeripheral to be 

ean set to true if the unit is 
reable^ false if the unit is 
elusive use. 

ared, assigned* claimed for the 
ny previous tentative allocations* 
an set to true if the allocation 
9 false if it cannot. 
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3.^.1 TABLE SPECIFICATION 

TABLE N/VMF t "system name of table" 

Puroose: "one line description" 

Usages "reason for existence" 

Creator! "system module building table" 

Readers: "system modules" 

Writers: "system modules" 

Reference: "other tables/structures pointed at" 

Declaration: "SWL declarations/definitions" 
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3.^.1 TABLE SPECIFICATION 

011500 "$s" 

01160 0" 

011700table name: logical file descriptor (ltd) 

OllSOOpurpose: an I f d is the primary control block for an Instance 

011900 of open of a file. 

012000usage2 the Ifd contains all information necessary to describe 

012100 an instance of open of a file, the Ifd contains 

012200 the working storage and current file status for the 

012300 file access procedure that processes user requests 

012400 against the file. 

012500creator: the Ifd is created at file ooen time by the file access 

012600 procedure that processes requests against the file. 

12700readers: file access procedure 

0128 OOwri ters! file access procedure 

012900references: PFDX for file 

013000" 

013100 

0132 

013300"def ine temporary types for temporary buffer manager" 

013ffOQ 

013500 

013600 CONST 

013700 bufcount = 50? "max number of blocks" 

013800 TYPE 

013900 bct_entry = RECORD 

014000 biknum: integert 

014100 blk_all ocatedS boolean, 

014200 bikptr: -*array£ * ] OF char, 

014300 RECENO; 

014400 

014500"def ine logical_f i I e_descript ion__tabI e" 

014600 

014700 TYPE 

014B00 rel_fap_lfd = RECORD 

014900 job_id: os#k j l_ordi na I , 

015000 cur_rec_otr: r el_f i leaddress ♦ 

015100 auth_func_codes : rm#requests_set , 

015200 rn_inc: boolean, 

015300 locking: boolean, 

015350 lockopt: rm#reserve_option, 

015400 cur_blk_num: integer, 

015500 timeout: integer, 

015600 bikptr: ~array[ * 3 OF char, 

015700 ofdxp: ''rel^fap^pfdx, 

015800 RECENO; 
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3.5 OPERATING SYSTEM REQUEST/RESPONSE STATUS FORMAT 



All IPLOS Request processors that return status information 
will use a system standaird status record format. The system 
message generator will also use the same record format as input. 



SWL Record format! 

TYPE 

OS#STATUS = RECORD 

level: 0. .off (16), "general level Indicator" 
FROMt STRING (2) OF CHAR, "issuing OS section" 
ST^COOE: Q..0FFFF(16) ^specific status code" 
MESGX STRING (32) of CHAR, "message mask" 
RECEND? 



where: 



LEVEL - Indicates the generat status, the values of which are 
shown in the following table. 

FROM - Indicates the Operating System category that issued 
the status 

ST_eODE - Indicates the specific code issued by convention 
threat the upper digit as a category and the 
remaining digits as specific errors within a 
category. 

Ixx - parj^meter errors 
2xx - access errors 
3xx - functional errors 

. fto be supplied) 
9xx - internal condition rejects 
Axx - internal error rejects 
Fxx - unidentifiable problem 

MESG - One or more character insertion strings with asterisk 
(*) separators (first character of the message will be 
used as separator). The total ler^gth of the text 
string including separators is 32 characters. The 
message generator references a message dictionary with 
a key based on the request status code and message 
text with asterisk substitution indicators. 
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3.0 CODING/DOCUMENTING CONVENTIONS 

3.5 OPERATING SYSTEM REQUEST/RESPONSE STATUS FORMAT 

1 + ♦ ♦ + + 1 

2 S=I0J^I8ICI 2 

3 I 1 I 5 I 9 J D I 3 
'f I 2 I 6 I A I E I h 

5 STATUS I 3 I 7 I B I F I 5 

6 • : '+ + ■»■ + — ^--1- 6 

7 Accented I x I x I I I 7 

8 Completed I x I I I I 8 

9 Not completed I I x I I I 9 

10 .11111 10 

11 Rejected I I I x I x I H 

12 User problem I I I x I I 12 

13 System problem I I I I x I 13 
IZf + + + + + it^ 

15 15 

16 EXAMPLE 16 

17 17 
1« Status "8AP701" '*MYFILE*^7' 18 

19 19 

20 3 - rejected, user oroblem 20 

21 21 

22 AP - issued by Access Procedures 22 

23 23 

24 701 - recorded data boundary encountered Zk 

25 25 

26 Message Dictionary 26 

27 27 

28 key - 8AP701 28 

29 29 

30 text - 'END OF DATA ON ♦ AT RECORD ♦' 30 

31 31 

32 Diagnostic Generated 32 

33 33 
3** 'END OF DATA ON MYFILE AT RECORD 47' 34 

35 35 

36 36 

37 37 

38 38 

39 39 

40 i^o 

41 41 
^2 . 42 
'*3 ,,3 

44 t,k 

45 45 

46 r»6 

47 1,7 

48 48 
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^.0 PRODUCT S£T INT^RFAgE^ 1 

2 
3 

5 

6 

J 

This area will contain information about the executed 8 

compiler environment (Parameters, errors* IN, OUT, OBJECT^ DEBUG, 9 

line numbers, LGO example and general loader facilities. 10 
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5.0 SA MPLE REQUE STS 1 

2 
3 

5 

6 

7 

This area will contain same sample requests (get/out t read^ 8 

open, access interrupt) and how control will flow upon their 9 

execution. 10 
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6.0 SI£AI££I 



This area will describe the O.S. position and understanding 
of selected general topics. 



6-1 HULTIPROC ESSORfS) 



o Multiprocessing is primarily a throughput faci I ity. 

o The O.S. will externalize two levels of multiprocessing 
to the end user. 

o The O.S. itself should be constructed in a manner which 
allows mul t iproccessing to occur. (Splits at natural 
asynchronous^ boundaries. i.e.* I/O scheduling) 

o The O.S. will support processors of differing types 
(e.g., PO - PI, P2 - P^, Emulators, •••) 



6.2 CO MPAT IBILITY 



The O.S. will support emulation services as requested by 
the emulator projects only. 

Emulation support will be introduced into the system via 
the subsystem conventions. 



Compatabil ity at the operator console will not 
supported. 



be 



The O.S. will support conversion from one code to another 
on the. fly. Mixed data files must be processed by a 
program which understands the static form of the data. 

The general model for work supported by the O.S. is 
described in the System Command Language document. 
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6.3 VIRTUAI, MEMORY A.NQ PRQT^CTXON 



o The Virtual Memory and Protection mechanisms in the 
hardware offer more capability than the Operating System 
wi I I use, init iai ly . 

o Virtual memory will aid the O.S. in managing large 
physical memory and reducing the impact of large changes 
in physical memory sizes and types. 

o The O.S. is not relying on a paging device. 

o The O.S. will not externalize ring(s) and keys to the end 

user in VI. 0. 

o The O.S. will use rings to implement the multiple monitor 
concept. Use of keys and locks will not be in V 1.0. 

o Rings and rules for their use must be externalized to the 

subsystem writer. 

o The O.S. must allow for multiple protection levels to be 
introduced. For example it should be possible for an 
installation - to force all file requests through an 
installation - surpplied subsystem and guarantee that no 
other oath can be taken. 



6.4 SH ARIN G 



o The OS will support sharing of code, which implies that 
compilers must generate pure procedures. 

o The O.S. will allow shared access to data (via virtual 
memory and explicit input and output) and will provide 
service routines to assist the user in contralling shared 
access. 



6.5 loss 



Requirements Draft: 
Dated November 5, 1974 
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6. 6 N£Iil5EKS 



For purposes of IPLOS implementation it will be assumed 
that host-to-host networks will not be required in V 1«0« 

IPLOS design will track the design plans for general 
networks as defined by CDC and NCR. 

A general mode of design and implementation of IPLOS will 
be to provide the basic routines and services to allow 
general computer-to-computer communications and to rely on 
library routines and user code to actually control the use 
of such services (i.e.t networking will not be an 
automatic, transparent function of IPLOS V l.O) • 



6.7 £AS 



o IPLOS will be designed to operate in an unattended manner- 

o A primary goal of IPLOS will be to detect and isolate all 
errors in system operation and use. User handling of 
errors will be supported wherever feasible. 



The IPLOS will 
configurations . 
where feasible. 



be designed to function in degraded 
Automatic reconfiguration will occur 



o An accurate history file of all relevant data pertaining 
to any error in system operation will be captured and 
saved. 



Support for allowing use of 
production environment will 
dearee feasible. 



diagnostic services in a 
be provided to the maximum 



o Multiple levels of job and system checkpoint and recovery 
will be provided in the design of IPLOS. Version 1.0 will 
be mostly concerned with system recovery support. 

o A major goal of the IPLOS design and^ imblementat ion will 
be to allow the modification and/or replacement 
of any system module in a controlled manner in a 
production environment. 
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ASL will initiate a project to study implementation of 
TOX/RSX (NCR) on IPL. 

A form of transaction processing will coexist with the 
O.S. and be a subset performance and feature wise of 
TOX/RSX. (Use Subsystem interface) 

O.S. will externalize physical I/O interfaces which a 
TOX/RSX type system will use. 



6.9 CONFIGURATION 

O.S. Design Target 3 MBYTE - P2 
1 MBYTE - PI 
Peripherals unknown. 
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